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sponding to the start of chapters. However, there is generally a limited number of chapters in a DVD file, and conse- 
quently a limited number of reference points, and such reference points are not directed to mapping time offsets. Such 
data offset files are of little use in searching for particular points in a file, other than the start of chapters. 
[0017] The present invention seeks to remedy problems encountered with the above prior art. 
[0018] Accordingly, there is provided a table comprising at least one record mapping a respective data offset in a 
file containing a representation of a bitstream to a corresponding time offset in the bitstream. 

[0019] Thus, data in a file corresponding to a particular time offset in the bitstream may be accessed rapidly, and 
efficiently. 

[0020] As used herein the term "bitstream" preferably connotes data comprising a series of bits arranged, for instance, 
temporally. The term bitstream is used interchangeably with the term datastream. A bitstream may comprise audio/ 
visual data or be representative of such audio/visual data, or it may comprise, or be representative of, teletext infor- 
mation, subtitles, any other type of text information, numerical information, or computer data, including computer pro- 
grammes. 

[0021] Digital and satellite TV transmissions generally comprise at least one bitstream comprising audiovisual data 
or a representation of such data. However, data transmitted or stored in or between any digital device, for instance 
computer devices, processors, A/D convenors, televisions, HDVRs, or storage devices for instance hard disks, tapes, 
computer storage devices, CDs, or DVDs may comprise a bitstream or a representation of a bitstream. 
[0022] A time offset may be the offset in time of a particular point in a bitstream from a defined point, for instance 
the start of the bitstream. A data offset in a file may be a position in memory in relation to a defined position, for instance 
the start of a file. If a bitstream is stored as file comprising a series of bits in a memory, then the data offset may be 
the number of bits from the start of the file, for instance. 

[0023] As used herein the term "table" preferably connotes data comprising at least one data point. A table may map 
such at least one data point to at least one other data point of the same or different type, directly or indirectly. A table 
may be In the form of a database, spreadsheet, or a file stored for instance in an electronic data storage device, for 
instance a hard disk, floppy disk, CD, DVD, or optical storage device, or a non-electronic storage device, for instance, 
a print-out. The term "table" as used herein also connotes an algorithm or process for generating such data point or 
points. 

[0024] In particular, audio/visual data may be in the form of a bitstream representative of a frame or series of frames. 
Such a bitstream may comprise a series of bits representative of pixels or points in such frames. A film or other sequence 
of moving images may comprise a series of frames, and each frame may be representative of a different image. As- 
sociated audio information, and indeed other information, such as conditional access or entitlement information, may 
also be included in such bitstreams. 

[0025] Preferably, the bitstream is a variable bitrate bitstream. 

[0026] Thus, data in a file corresponding to a particular time offset in the bitstream may be accessed rapidly and 
efficiently, even if there is not a linear relationship between data offset throughout the file and time offset throughout 
the bitstream. 

[0027] As used herein, the term "variable bitrate bitstream" preferably connotes a bitstream comprising a series of 
bits representative of data which may vary with a parameter, for instance time or location, and for which the number 
of bits representative of one portion of the data at a particular value or range of values of the parameter may be different 
to the number of bits representative of another portion of data at another value or range of values of the parameter. 
[0028] So, for instance, if a bitstream comprises a series of bits representative of an image frame, and the number 
of bits required to represent a portion of this image, for instance a foreground object, is greater than the number of bits 
required to represent another portion of the image, for instance a plain background, then the bitstream may be a variable 
bitrate bitstream and the data offset in the bitstream, or in a file containing a representation of such bitstream, may not 
vary linearly with a spatial offset in the image frame itself. 

[0029] In a bitstream comprising, for instance, a series of bits arranged temporally, the bitrate may be the number 
of bits per unit time in the bitstream, and a variable bitrate bitstream, may then be a bitstream in which the number of 
bits per unit time may vary with time offset. 

[0030] If a bitstream comprises a series of bits representative of a series of periodically spaced, time-varying image 
frames, for instance a film, and the number of bits necessary to represent one frame is less than the number of bits 
necessary to represent another frame then the bitstream may be a variable bitrate bitstream, and a data offset in a file 
containing a representation of the bitstream may not vary linearly with a time offset in the bitstream, or in the film itself. 
[0031] Such variable bitrate bitstreams may comprise compressed or encoded digital data (or representations of 
such data), such as data transmitted to, stored at, or generated by HDVRs, or indeed any video or audio device, such 
as devices included in, or associated with a set top box, or computers, processors or mass storage devices, such as 
a hard disks, or DVDs. Such variable bitrate bitstreams may include data in a variety of compression formats, including 
MPEG-2, MPEG-4, MP3 protected by different ciphering algorithms including DVB-CS, DES, 3DES, and may contain 
video and or audio data, teletext information, subtitles, any other type of text information, superimpose data, computer 
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frames. Similarly, if the frequency with which key frames occur in a bitstream varies, the period of the time offsets of 
the index points can vary so that index points and key frames coincide. 

[0051 J The period of the time offsets can also be chosen to match other characteristics of the bitstream. 
[0052] Preferably, the bitstream comprises at least one portion of bitstream data which can independently be used 
5 to regenerate a respective at least one portion of audiovisual data, and the time offset of the at least one record cor- 
responds to the respective at least one portion of bitstream data. 

[0053] Such portion of data may be a key frame, for instance in an MPEG bitstream, and or may be representative, 
for example, of a background image, or overlay image. Such portion of data may be accessed directly and immediately, 
and representative output of audio/visual data may be obtained rapidly at different points throughout the bitstream. 
io [0054] Preferably, the at least one portion of bitstream data comprises a key frame. 

[0055] Preferably, the bitstream comprises MPEG data, and the at least one portion of bitstream data comprises an 
intra-frame. 

[0056] Preferably, the bitstream comprises at least one further portion of bitstream data which can be used to regen- 
erate a portion of audiovisual data in conjunction with the at least one portion of bitstream data, and preferably the at 

is least one further portion of bitstream data comprises a delta frame. 

[0057] Thus smooth, rapid, and efficient operation of processes such as fast-forwarding, rewinding and skipping can 
be enabled. The potential maximum speed of these operations may also thus be increased, as the speed with which 
key frames can be located may be increased, and as there may be no need to process dependent portions of data, 
such as delta frames, or only a limited number of such dependent portions of data may need to be processed. 

20 [0058] Preferably, the table is generated automatically during recordal of the representation of the bitstream in the file. 
[0059] Thus, no further processing of the recorded bitstream is necessary after recordal of the bitstream is complete, 
and the HDVR index table is in place even if the recording is interrupted or terminated. 

[0060] Preferably, at least one record in the table is mapped to a respective at least one further record, and preferably 
the said at least one further record comprises conditional access information or content management information. 

25 [0061] Such content management information or conditional access information may be, for instance, a control word 
(CW), or CMMs, ECMs, EMMs, URMs, or associated information, which may be associated with data located at a 
particular value or range of values of data offset or time offset. Typically, the bitstream may be divided into time seg- 
ments, or cryptoperiods (encompassing a range of time offsets), and the further record may be associated with a 
particular cryptoperiod or plurality of cryptoperiods. The further record may also be associated with, for instance, chap- 

30 ters, or with files as a whole, or with particular users or groups of users. Access to data may be enabled rapidly and 
efficiently by reading stored related information corresponding to particular data offsets or time offsets. Such rapid 
access to data may be particularly important in respect of processes such as fast-forwarding, rewinding, or skipping. 
[0062] In particular, the further record may comprise a CMM or plurality of CMMs. 

[0063] If the point in the table maps to a data offset in a file which does not correspond to the start of a cryptoperiod, 
35 then the HDVR would generally not have access to the CMM , or a pointer to such CMM, or other content management 
or conditional access information, necessary to decode the data at that point. The HDVR would typically have to read 
consecutively forward or backward through the file in order to find the next set of such information or pointer to such 
information in order to begin decoding data. By mapping at least one record in the table to at least one further record, 
conditional access or content management information applicable to the point in the file indexed by the record can be 
to provided, and data from this point can be decoded immediately, without first having to read through the file to find such 
information. This feature is of particular advantage if data at a number of points in a file needs to be read consecutively 
and rapidly, for instance in performance of certain trick mode operations, such as fast forwarding or rewinding. 
[0064] The further record may also comprise, for instance, comments, which could be displayed on a screen, or 
commands, such as television control commands. Alternatively, the data could be related to a parental control mech- 
45 anism. Such parental control mechanism may be directed to particular chapters, but may also be directed to cryptope- 
riods and pluralities of cryptoperiods, and user defined portions of a file. 

[0065] The further record may be stored in the table of records, or in a separate file or table, or the table of records 
and or the related information may be stored with the file, for instance in a header. 
[0066] Preferably, the said at least one further record is stored in a further table. 
so [0067] The entries in such a further table may be mapped easily to entries in the table mapping data offsets to time 
offsets. 

[0068] Preferably, the said at least one further record is inserted upon command of a user. 

[0069] Thus, a user may add, or indeed remove, information relating to characteristics of a programme or a bitstream. 
For instance, a user may select particular scenes within a recorded film to which they wish to control access, and such 
55 access could be controlled by addition or amendment of a record activating a parental control mechanism. 

[0070] Preferably, the said at least one record in the table is mapped to the respective at least one further record 
upon command of a user. 

[0071] Thus, a user can control which records are associated with which further records. 
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[0072] Preferably, the file is encoded and the at .east one record maps a data offset In the encoded file to a corre- 
sponding time offset in the bitstream. ,. ti!traQm 
[0073] Preferably, records are inserted in dependence upon charactenst.es of the bitstream. 
[0074] Preferably, at least one record is inserted upon command of a user. 
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rnnail As before the bitstream is preferably a variable bitrate bitstream. 
[0091] Preferably, the said at least one further record is stored in a further tab.e^ 
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[0096] Preferably, at least one record is inserted upon the command of a user, 
mnon Preferably at least one record is inserted automatically. 

through the file bit-by-bit until they reach the desired point, for example, 
in the file and time offset in the bitstream. 
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[01031 Preferably, the desired portion of data is representative of bitstream data which can independently be used 
to regenerate a further portion of data 

[0104] The further portion of data may, for instance be audiovisual data, and the desired portion of data may be a 
key frame. 

[0105J Preferably, the step of jumping to a position in the file comprises reading a record from a table as herein 
described and jumping to the data offset given in the record. 

[01061 Preferably, the step of jumping to a position in the file comprises reading a record from a table as herein 
described and jumping to the data offset given in the record, and the at least one further record is used in the step of 
reading data. 

[0107] The at least one further record may be conditional access information, or content management Information, 
and may in particular be a CMM or a plurality of CMMs. The further record may be used to decode the data In the file! 
[0108] Preferably, the data offset in the record corresponds to the desired position in the file. 
[0109] Thus the desired point can be found by jumping to the point in the file corresponding to the data offset in the 
file, without the need to read additional data before locating the desired point in the file. 

[0110] In a further aspect, there is provided a method of searching a file containing a representation of a bitstream 
for a plurality of desired portions of data, comprising searching for each desired portion of data using a method as 
described herein. 

[0111] Thus a series of desired points in the file can be located quickly and efficiently, and data at these points can 
be read. 

[0112] Preferably, the desired portions of data are representative of portions of bitstream data which are periodically 
spaced in time. 

[01 13] Thus, portions of the bitstream which are equally spaced in time can be located and read quickly and efficiently, 
which may enable quick and efficient performance of trick mode operations, such as fast forwarding or rewinding, on 
the stored bitstream. 

[0114] Preferably, the desired portions of data are used to effect a fast forwarding or rewinding operation. 

[0115] The desired portions of data are located and read, typically using associated CMMs, and the resulting data, 

usually audiovisual data, may be output to a display device. 

[01 16] Preferably, the time period between the portions of bitstream data represented by the desired portions of data 
is chosen to effect a given fast-forwarding or rewinding speed. 

[0117] Preferably, the time period between the portions of bitstream data represented by the desired portions of data 
is chosen in dependence upon a characteristic of a means used to carry out the method. 

[0118] The maximum rate at which data may be located, read and displayed by a means, such as an HDVR in 
conjunction with a display device, is dependent upon characteristics of such means, and may be dependent upon 
either hardware or software characteristics. A given fast forwarding or rewinding speed, for instance, may only be 
sustainable if a certain proportion of the data in the stored file is played back. For instance, it may not be possible to 
play back all data in the file at a faster than normal rate. On the other hand, if the proportion of data which is played 
back is limited too severely, image quality for instance may be degraded. 

[0119] Preferably, the characteristic is the maximum sustainable rate of retrieval or processing of data from the file. 
[0120] By varying the time period between the portions of bitstream data, the maximum sustainable rate of retrieval 
or processing of data from the file can be obtained, for given characteristics of the means. Thus, for instance, the 
optimum picture quality may be obtained for a given fast forwarding or rewinding speed. 

[0121] Preferably, the characteristic is a read/write hard disk access time, or a parsing demultiplexer bandwidth, or 
an operating system scheduling accuracy. 

[0122] Preferably, the given fast-forwarding or rewinding speed is varied upon command of a user. 

[0123] In a further aspect, there is provided a file, comprising a representation of a bitstream, and a table as described 

herein. 

[0124] In yet further aspects, there is provided a processor for generation of a table as described herein, and a 
processor for analysis of characteristics of a bitstream and insertion of records in such a table in dependence upon 
this analysis. 

[0125] There is also provided a storage means for storage of a table as described herein, and preferably the storage 
means is adapted for storage of the file containing a representation of a bitstream. 

[0126] There is also provided a hard disk video recorder comprising a storage means as described herein and pref- 
erably further comprising a processor as described herein, and a receiver/decoder comprising such a hard disk video 
recorder. Preferably there is also provided a broadcast system incorporating such a receiver/decoder. 
[0127] In a further aspect, there is provided a receiver/decoder adapted to communicate with a hard disk video 
recorder as described herein, and a broadcast system incorporating such a receiver/decoder. 

[0128] The invention further provides a computer program and a computer program product for carrying out any of 
the methods described herein and/or for embodying any of the apparatus features described herein, and a computer 
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lmh^„« ediUm , IT'" 9 St ° red there ° n 3 Pr ° gram for Carrying out of the methods described herein and/or for 
embodying any of the apparatus features described herein. 

Eh.H T !!ili Vent !, 0 / n T° ^ri? 68 3 Si9nal embod y in 9 a c ° m P uter P»Q™«i for carrying out any of the methods 
T^n ■ T embodying any of the apparatus features described herein, a method of transmitting such 

ofT nLthl 3 °r P T. '?l haVin9 an ° Perating SyStem Which supports a ^Puter program for carrying out any 
[0130] Turning to consideration of further aspects of known systems, some known systems are able record to hard 
disk received scrambled bit streams (that is, the encoded digital television signals). In one such system, thebit stream 
is retained in the compressed and scrambled form when recorded it, but the recording is then only valid for the duration 
of the exploitation key (which is replaced on a regular basis). One technique which overcomes this problem essentially 
constats of extracting Entitlement Control Messages (ECMs) from the bit stream before it is recorded, decrypting the 
ECMs as per usual, re-encrypting the ECMs with an internal exploitation key (unique to each subscriber), and inserting 
he ECMs back into the bit stream in their original positions (all the time not altering the control words used to scramble 
the bit stream). This has the desired effect of increasing security, but is complicated to implement, not least because 
intense P ° Siti ° n °* ^ E ° M Withi " ^ " StrSam be determined P reci sely, which is very computationally- 

[0131] The present invention also seeks to remedy problems in the above and other prior art 
[0132] Accordingly, in a further aspect of the invention, there is provided apparatus for evaluating a position in a bit 
stream, comprising means for estimating the position. 
20 [0133] By estimating the position, instead of determining it exactly, for example, the process of evaluating the position 
can be made more efficient. 

[0134] The position is preferably the spatial position of a data packet, such as an MPEG table, within the bit stream 
It may alternatively be the temporal position within the bit stream, measured in seconds, for example Preferably the 
apparatus is adapted to operate in respect of a bit stream being processed in real-time, but it may also be adapted to 
operate in respect of a static and/or random access bit stream. Furthermore, the bit stream preferably contains pack- 
etised (such as MPEG format) and/or audio/visual data. 
[0135] The term "audio/visual" as used herein preferably connotes either audio or visual matter, or a combination of 
the two. In the context of a broadcast signal received by a receiver/decoder, the term may encompass subtitle teletext 
synchronisation and other data transmitted in close relation to audio and video components making up a television 
30 programme. 

[0136] The means for estimating the position is preferably adapted to estimate the position in dependence on a 
known position in the bit stream. The known position could be, for example, a transition between different portions of 
the bit stream. The dependence of the estimation on a known position in the bit stream can allow the estimate to be 
made more precisely. 

35 [0137] In a preferred embodiment, the apparatus further comprises means for selecting the known position from a 
plurality of alternatives. This can allow the estimate to be further refined, by increasing the selectivity of the process 
[0138] Consequently, the means for selecting the known position is preferably adapted to select the known position 
in dependence on its proximity to the position to be evaluated. 

[0139] Thus, while the position to be estimated may not itself be easily or at all determinable exactly it may be 
possible to determine known positions which are near to the position to be estimated, preferably in preference to other 
known positions which are not as close to the position to be evaluated. This can allow the accuracy with which the 
position is estimated to be more appropriately limited in accordance with at least one known position in the bit stream 
[0140] The means for selecting the known position may be adapted to select systematically one of the two known 
positions closest to the position to be evaluated. This can further improve the accuracy of the estimation. In particular 
the known position may be chosen to be the closest position either before or after the estimated position In either 
case, this can bias the estimate of the position either generally backwards or generally forwards in the bit stream 
respectively. Alternatively, the known position may be chosen to be the closest position in either direction, which can 
result in no genera! bias of the estimate. 

[0141] Furthermore, the means for selecting the known position may be adapted to select the known position as a 
transition in the bit stream between a first and second portion of the bit stream. Such first and second portions could 
be, for example, segments of the bit stream transferred in direct memory access (DMA) data transfers 
[0142] This can make the estimation more efficient by making use of existing divisions of the bit stream when deter- 
mining the known position. One of the portions of the bit stream may contain the position to be estimated 
[0143] Preferably the means for estimating the position may be adapted to estimate the position as an offset from 
the known position, thereby allowing time-displacement effects to be taken into account in the estimate The offset 
may be zero, in which case the estimated position is equal to the known position or it may be positive or negative 
[0144] Furthermore, the means for estimating the position may be adapted to estimate the position in dependence 
on a buffer size. Preferably the position is estimated by, amongst other things, adding the buffer size to the known 
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position. The buffer size (preferably defined as a maximum size, or alternatively expected or exact size) may relate to 
a buffer used to transport the bit stream, such as a FIFO, for example. By estimating the position in dependence on 
the buffer size, in effect consideration can be taken of the uncertainty and/or delay arising from the use of such a buffer. 
[0145] Alternatively or additionally, the means for estimating the position may be adapted to estimate the position in 
dependence on a security parameter. In particular, the position may be estimated by, amongst other things, adding the 
security parameter to the known position. The security parameter may be negative or positive, and is preferably em- 
ployed as a 'safety factor' to ensure that the estimate either exceeds or remains within a critical value, and can alter- 
natively or additionally encapsulate into a single correction factor a plurality of uncertainties or biases influencing the 
estimate (such as possible timing errors, software latencies, unknown packet sizes, and so on). 
[0146] In the preferred embodiment, the apparatus may further comprise means for storing the bit stream. This means 
for storing preferably comprises a controller for causing the bit stream to be stored, but may alternatively or additionally 
comprise a corresponding storage device, such as a hard disk. This can improve the versatility of the apparatus. 
[0147] In this case, the apparatus may further comprise means for storing data associated with the bit stream sep- 
arately from the bit stream. The data associated with the bit stream preferably comprises at least one of the estimated 
position, data corresponding to the estimated position, and information which can allow the data corresponding to the 
estimated position to be synchronised with the stored bit stream. The means for storing data associated with the bit 
stream separately from the bit stream is preferably adapted to store conditional access data. 

[0148] This important feature is also provided in respect of a related aspect of the invention, which provides apparatus 
for manipulating a bit stream, comprising means for receiving conditional access data, means for synchronising the 
conditional access data with the bit stream, and means for storing the bit stream. 

[0149] By synchronising conditional access data with the bit stream, reliance can be reduced on any conditional 
access data within the bit stream itself. 

[0150] As mentioned above, the apparatus preferably further comprises means for storing the conditional access 
data separately to the bit stream. However, the apparatus may instead comprise means for storing the conditional 
access data in the bit stream, by multiplexing or otherwise reinserting the data into the bit stream, for example. In the 
former case, the conditional access data may be included in a separate part of a file also containing the stored bit 
stream, or it may be stored in a separate file or in a different storage medium. 

[0151] This can improve the efficiency with which the conditional access data is managed, for example by allowing 
faster access to the generally smaller volume (with respect to the corresponding bitstream) of conditional access data. 
[0152] The means for synchronising is preferably adapted to create a reference between the conditional access data 
and a corresponding position in the bit stream. The apparatus more preferably further comprises means for storing the 
or each reference with or in close proximity to the conditional access data and/or bit stream. This can facilitate the task 
of synchronising the conditional access data with the bit stream. 

[0153] The apparatus may in addition comprise means for storing the reference in a table, which can further facilitate 
access to the conditional access data, for example, during reproduction of the bit stream. 

[0154] The means for synchronising is adapted to select the referenced position (that is, the 'corresponding position* 
in the reference between the conditional access data and a corresponding position) from a range of safe values. 
[0155] The range of safe values preferably comprises an actual position in the bit stream corresponding to the con- 
ditional access data, this being the position in the bit stream at which the conditional access data (or a copy thereof) 
is actually transmitted. 

[0156] If the means for synchronising is adapted to select the referenced position such that it falls within a portion 
of the bit stream to which the conditional access data corresponds, the means for synchronising is preferably further 
adapted to select the referenced position such that it falls within a cryptoperiod to which the conditional access data 
corresponds. 

[0157] This matching of the referenced position with the cryptoperiod to which the conditional access data corre- 
sponds can improve the quality of the synchronisation between the bit stream and conditional access data. 
[0158] Preferably the means for synchronising is adapted to select the referenced position in dependence on an 
event signifying the receipt of the conditional access data by the receiving means. This can allow the bit stream and 
conditional access data to be yet more closely synchronised. 

[0159] As previously mentioned, the apparatus may further comprise means for estimating a position in the bit stream, 
but also with the referenced position being selected in dependence on the estimated position. 
[0160] If as is preferred, the apparatus preferably further comprises means for transferring the bit stream in a plurality 
of discrete segments, the means for estimating the position is preferably adapted to estimate the position in dependence 
on an end of one of the segments, and furthermore the apparatus preferably further comprises means for predeter- 
mining the size of at least one segment. This can improve the flexibility of the estimation process, as the variation of 
the size of the at least one segment can directly or indirectly affect the estimate itself and the stability of the estimation 
process. 

[0161] The predetermination preferably involves setting the size of the segment, although it may alternatively involve 
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detecting the size of the segment. Possibly depending on factors such as system performance, FIFO and hard disk 
size, each segment could be as small as 1 bit and as large as 100 Mb or even greater, for example. For efficiency, 
values between approx.mately 1 Mb and, say, 6 Mb may be appropriate for a typical MPEG audio/visual bit stream 
however. The mean, for transferring may, for example, be a direct memory access (DMA) controller, a mass storage 
device, a FIFO and/or FIFO manager, and so on. 

[0162] In a related aspect of the invention, there is provided apparatus for manipulating a bit stream, comprisinq 
means for transferring the bit stream in a plurality of discrete segments, and means for estimating a position in the bit 
stream in dependence on a property of one of the segments. 
[0163] Such a property could be segment size, for example. 

[0164] As mentioned previously, preferably the means for estimating a position is adapted to estimate the position 
of conditional access data, such as an ECM. in the bit stream. Also as mentioned previously, the apparatus preferably 
further comprises means for predetermining the size of a segment, which as noted can increase the flexibility of the 
estimation. 

[0165] The means for predetermining the size is ideally adapted to predetermine a size equivalent to less than a 
portion of the bit stream associated with the position. Such a portion may be a predetermined number of cryptoperiods 
in which case the number of cryptoperiods need not be an integer, and indeed may be, for example, slightly less than 
a whole number to take into account the effect of FIFO buffers. This can ensure the safety of the estimation 
[0166] The means for predetermining the size may also or alternatively be adapted to predetermine the size in de- 
pendence on a characteristic of the bit stream. By determining the size of a segment in dependence on a characteristic 
of the bit stream, account can be taken of factors related to the bit stream which may affect the accuracy of the estimate 
for example. J 

[0167] Furthermore, the means for predetermining the size may be adapted to predetermine the size in dependence 
on a bit rate of the bit stream. Preferably this bit rate is an average bit rate, which may be computed in respect of the 
segment in question, or any other portion of the bit stream which preferably contains the position. 
[0168] If the means for predetermining the size is adapted to predetermine a constant size, the means for predeter- 
mining the size may moreover comprise a static filter. If, on the other hand, the means for predetermining the size is 
adapted to predetermine a variable size, the means for predetermining the size preferably comprises a dynamic fitter 
[0169] Both types of filter preferably accept as an input at least one characteristic of the bit stream, and produce as 
an output a desired segment size. Indeed, preferably a number of filter coefficients are used, corresponding to a series 
of characteristics of the bit stream. 

Such characteristics could be as described above. The filter can be implemented in software, under the control of a 
digrtal signal processor (DSP), coprocessor, or main processor, for example. The term 'filter' as used herein preferably 
connotes a process or apparatus for transforming at least one input into at least one output; such filters could be seen 
as the product of a mathematical formula whose variables are the filter inputs. 

[0170] Furthermore, the means for predetermining the size may comprise at least one of a rapid dynamic filter an 
inertial dynam.c filter, and a hybrid dynamic filter. The rapid and inertial filters may be characterised in having relatively 
few and relatively many input values, respectively. The hybrid filter may be characterised in having properties of both 
the rapid and inertial filters, and is preferably effectively a combination of a rapid and an inertial filter, with the overall 
filter output selected as the output of a particular one of these two sub-filters in dependence on a particular constraint, 
such as whether or not a particular input is increasing or decreasing. 

[0171] The means for estimating the position may be adapted to take into account an error in at least one previous 
estimate. Such an error could be, for example, a time difference observed a posteriori between an estimated position 
and an actual position. This can allow the estimate to be refined over time. 

[0172] The apparatus may further comprise means for estimating the position in dependence on at least one char- 
acteristic of the bit stream. This can produce a yet more accurate estimate particularly where, for example more 
information is available regarding the bit stream. 

[0173] This important feature is also provided independently. Accordingly, in a related aspect of the invention there 
is provided apparatus for evaluating a position in a bit stream, comprising means for estimating the position in depend- 
ence on at least one characteristic of the bit stream. 

[0174] The or each characteristic is preferably at least one of a bit rate of the bit stream, the relative position within 
the bit stream, and the time elapsed between parts of the bit stream. 

[0175] The apparatus may further comprise means for estimating a measure of separation between the occurrence 
of the position and the occurrence of an event relating to the position. Such a measure of separation could be the time 
At discussed below, for example. This can provide more information with which to make a better estimate. 
[0176] The means for estimating the position in the bit stream is preferably adapted to incorporate the measure of 
separation, preferably in conjunction with an estimate of the bit rate of the bit stream close to the position in the bit 
stream. This can further refine the estimation process. 

[0177] The means for estimating a measure of separation is preferably adapted to measure the separation between 
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the occurrence of the position and the end of a processing operation. 

The processing operation is preferably related to the processing of data associated with the position In the bit stream. 
[0178] In a further related aspect of the invention, there is provided a receiver/decoder incorporating apparatus (in 
any of the various aspects) as aforesaid. 
5 [0179] There is also provided, in a yet further aspect, a method of evaluating a position in a bit stream, comprising 
estimating the position. 

[0180] In another aspect of the invention, there is provided a method of manipulating a bit stream, comprising re- 
ceiving conditional access data, synchronising the conditional access data with the bit stream, and storing the bit 
stream. 

10 [0181] In a further aspect of the invention, there is provided a method of manipulating a bit stream, comprising trans- 
ferring the bit stream in a plurality of discrete segments, and estimating a position in the bit stream in dependence on 
a property of one of the segments. 

[0182] In a yet further aspect of the invention, there is provided a method of evaluating a position in a bit stream, 
comprising estimating the position in dependence on at least one characteristic of the bit stream. 
15 [0183] In another aspect of the invention, there is provided a broadcast system comprising a broadcast centre and 
a receiver/decoder as aforesaid. 

[0184] In a further aspect of the invention, there is provided a computer program product adapted to carry out a 
method as aforesaid. 

[0185] In a yet further aspect of the invention, there is provided a computer readable medium having stored thereon 
20 a computer program product as aforesaid. 

[0186] In another aspect of the invention, there is provided a signal tangibly embodying a computer program product 
as aforesaid. 

[0187] The invention also provides a computer program and a computer program product for carrying out any of the 
methods described herein and/or for embodying any of the apparatus features described herein, and a computer read- 
25 able medium having stored thereon a program for carrying out any of the methods described herein and/or for embod- 
ying any of the apparatus features described herein. 

[0188] The invention also provides a signal embodying a computer program for carrying out any of the methods 
described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such 
a signal, and a computer product having an operating system which supports a computer program for carrying out any 

30 of the methods described herein and/or for embodying any of the apparatus features described herein. 

[0189] Turning to consideration of further prior art, video cassette recorders and also audio cassette recorders have 
become ubiquitous, having application in both domestic and professional environments. However, their principal short- 
coming is that data signals are recorded on a tape, and can therefore only be accessed serially. The tape must be fast- 
wound if a section of it is to be skipped, or to access a particular part of a recording. This is a relatively slow procedure. 

35 Moreover, many tape recorders, particularly of the low-cost type most commonly found in domestic applications, are 
incapable of reproducing a recording at a speed other than that at which it was recorded (for a slow-motion or accel- 
erated motion effect) or a single frozen frame of a recording without significant distortion of the display. 
[0190] High-capacity mass data storage devices, and in particular, hard disc drives, now have a storage capacity 
large enough to enable them to store a significant amount of digitally-encoded video and/or audio signals, particularly 

40 when such signals are encoded using an efficient compression algorithm such as MPEG. Any given piece of data 
stored on the device can be accessed, at least from the point of view of a human operator, essentially instantaneously. 
The availability of such devices has led to development of apparatus for recording and reproducing video and/or audio 
signals in which the signals are stored on such a mass-storage device. 

[0191] Implementation of video and/or audio playback apparatus using such mass storage has the potential to offer 
4* a user far greater operational flexibility than a conventional tape-based video and/or audio recorder, and gives devel- 
opers the opportunity to provide video and/or audio playback products that have a range of capabilities beyond those 
of a conventional tape recorder. It is a further aim of this invention to provide means by which a developer can make 
use these features offered by such playback apparatus. 

[0192] Accordingly, in a further aspect of the invention, there is provided a command for controlling the transfer of 
50 an audio/visual bit stream, wherein the transfer speed is represented as a parameter. 

[0193] The transfer is preferably the reproduction of audio/visual data, from a mass storage device to an audiovisual 
playback device (such as an MPEG decoder and/or video output device), for example. Alternatively (and not exclu- 
sively), the transfer may be the recording of audio/visual data, from a live broadcast (or other) signal source to a mass 
storage device, for example. 

55 [01 94] By being able to set the transfer speed via a parameter of the command, a number of different effects can be 
achieved with a call to the same command. Such a command could, for example, be used to control the operations of 
a virtual (or real) video recorder or other random access or sequential access storage device. The set_speed() com- 
mand described later is an example of such a command, applied principally to the reproduction of audiovisual data. 
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[0195] The term "audio/visual" as used herein preferably connotes either audio or visual matter, or a combination of 
the two. In the context of a broadcast signal received by a receiver/decoder, the term may encompass subtitle, teletext 
synchronisation and other data transmitted in close relation to audio and video components making up a television 
programme. 

[0196] The term "command" as used herein preferably connotes a physical manifestation of a software routine pro- 
grammed to carry out a specified function, preferably in the form of electrical impulses in a memory or in a more 
permanent form, such as a recording of the routine on a suitable data carrier, for example. Preferably the manifestation 
of the routine is immediately executable by a processor, being stored as object code, for example. The term may also 
be extended to cover the actual invocation of such a routine, either in the form of a physically-embodied instruction to 
execute the routine, or as an actual signal - such as a remote procedure call (RPC) - designed to cause the routine to 
execute. 

[0197] The speed may be positive, zero and/or negative. In the case where the transfer is a reproduction, if the speed 
is positive, the reproduction would preferably be one of normal playback, slow playback, fast forwarding, and stop/ 
pause. Alternatively, if the speed is negative, the reproduction would preferably be one of fast rewind and slow rewind 
Thus, by allowing such a range of speeds, the flexibility offered by the command can be increased. 
[0198] If the range of speeds is limited by hardware or other considerations, the maximum speed is preferably the 
equivalent of 2, 5, 1 0, 50, 1 00 or 500 times a normal transfer speed. Correspondingly, the minimum speed may be the 
equivalent of 1 , 0, -1 , -2, -5, -1 0, -50, -1 00 or -500 times the normal transfer speed (a minimum of 0 or more preventing 
the possibility of 'rewinding' the stream, in the reproduction case, and a minimum of 0 or less opening the possibility 
of storing an audio/visual bit stream in reverse, in the recording case). The range of speeds may be a continuous range, 
allowing smooth transitions between different transfer speeds, for example, or a discrete set of speeds, for example] 
possibly taking into account hardware limitations. The parameter of the command may, in fact, be an arbitrary speed 
which is converted into one of the discrete set of speeds, as appropriate, during the execution of the command or 
subsequently. 

[0199] The speed is preferably related to the parameter by a multiple of a normal transfer speed (such as the normal 
playback speed in the reproduction case). This can greatly simplify procedures invoking the command, since they 
might not need to calculate corresponding bit rates for reproduction of the bit stream, for example. In the recording 
case, the parameter may, for example, specify the desired frame rate (such that if it was lower than the normal frame 
rate, the command would cause frames to be discarded from the stored bit stream at an appropriate rate). 
[0200] If the speed was equal to the parameter multiplied by a normal transfer speed, for example, a parameter of 
1 would be equivalent to a normal transfer speed, a parameter of 0 would result in the transfer being paused, and a 
parameter greater than 1 would correspond to fast forwarding (in the reproduction case) or recording at a lower quality/ 
speed (in the recording case), for example. Alternatively, there may be a more complex relationship between speed 
and parameter, whereby a constant value is subtracted from either the speed or parameter, for example. 
[0201] Preferably a position from which the transfer is to take place is represented as a parameter. This can allow 
further flexibility in the transfer of an audio/visual bit stream. In the case where the transfer is the reproduction of audio/ 
visual data, the position from which the transfer is to take place is preferably an offset into the audio/visual data, and 
may be set to the nearest bit, byte, given other data multiple, given period of time, or frame of data, or may otherwise 
or additionally be specified in terms of programme or track numbers. Otherwise, in the recording case, for example, 
the position can be relative to a position on a mass storage device, setting the position at which recording is to start 
or continue. 

[0202] This important feature is also provided independently. Accordingly in a further aspect of the invention there 
is provided a command for controlling the transfer of an audio/visual bit stream, wherein the position from which the 
transfer is to take place is represented as a parameter. The set_pos() routine described later is an example of such a 
function. 

[0203] The parameter specifying the position from which reproduction is to take place may be related to a measure 
of time, which can free the invoking routine from calculations relating the time to the data offset in the bit stream. 
[0204] If, instead, the parameter specifying the position from which reproduction is to take place is related to an offset 
in the bit stream (or location on a mass^storage device, for example), the command can be more simply implemented, 
resulting in a saving of memory and increasing the speed of execution. 

[0205] In another aspect of the invention, the is provided a command set, comprising at least one command as 
aforesaid. This can allow a wide range of more specialised commands to be implemented easily, by using any of the 
above-mentioned commands as building blocks. 

[0206] This important feature is also provided independently, and accordingly there is also provided a command set 
for controlling the transfer of an audio/visual bit stream, comprising a command having the position from which repro- 
duction is to take place represented as a parameter and a command having the transfer speed represented as a 
parameter. 

[0207] In a further related aspect of the invention, there is provided a command for controlling the transfer of an 
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audio/visual bit stream, the command adapted to invoke at least one command as aforesaid. 

[02081 The command may be adapted to selectively invoke different further commands In dependence on a state 
relating to the transfer of the audioA/isual bit stream. Such a state could be, for example, whether the transfer was 
paused or not (in other words, whether or not the transfer speed was zero); in this case, the command could, for 
s example, call one further command when the transfer is paused, and a different further command when the transfer 
is in progress. 

[0209] This can allow the further commands to be simplified, since they could be written without having to take into 
consideration certain values of the abovementioned state. 

[0210] Alternatively or additionally, the command may be adapted to invoke a command (preferably for setting the 
10 transfer speed) as aforesaid, with a parameter equivalent to a normal transfer speed, and invoke a command (preferably 
for setting the position of reproduction) as aforesaid, with a parameter equivalent to a position in the audio/visual bit 
stream. Preferably such a command is adapted to start playback in the audio/visual bit stream, and may itself corre- 
spond to or be invoked by a 'play' or a 'seek and play' command. Also, such a command preferably has at least one 
parameter in the same format as at least one parameter of one or both of the invoked commands. 
15 [0211] The command may be adapted to invoke a command (preferably for setting the transfer speed) as aforesaid, 
with a parameter equivalent to zero speed. This command is preferably adapted to stop or pause playback of an audio/ 
visual bit stream, and may itself correspond to or be invoked by a 'pause' or a 'stop' command. The invoked command 
may also cause the display of the audio/visual bit stream to be ceased. 

[0212] The command may alternatively be adapted to invoke a command (preferably for setting the transfer speed) 
20 as aforesaid, with a parameter equivalent to a greater than normal playback speed. Preferably the command is adapted 
to fast-forward an audio/visual bit stream, and may itself correspond to or be invoked by a fast-forward' command. 
Furthermore, the command may be adapted to further invoke the command with a different parameter, for example to 
cause the bit stream to be reproduced faster the longer a 'fast-forward' button is depressed. 

[0213] The command may be adapted to invoke a command (preferably for setting the transfer speed) as aforesaid, 
25 with a parameter equivalent to a less than normal transfer speed. This command may be adapted to ptay in slow motion 
an audio/visual bit stream, and may itself correspond to or be invoked by a 'slow motion' command. 
[0214] The command may instead or additionally be adapted to invoke a command (preferably for setting the transfer 
speed) as aforesaid, with a parameter equivalent to a negative playback speed. Preferably this command is adapted 
to play in reverse an audio/visual bit stream, and may itself correspond to or be invoked by a 'rewind' command. 
30 [0215] Furthermore, the command may be adapted to invoke a command (preferably for setting the transfer speed) 
as aforesaid, with a parameter equivalent to a normal playback speed. Preferably this command is adapted to resume 
playback of an audio/visual bit stream, and may itself correspond to or be invoked by a 'play', 'pause' or 'un-pause* 
command. 

[0216] The command may be adapted to invoke a command (preferably for setting the position of reproduction) as 
35 aforesaid, with a parameter equivalent to the location. Preferably this command is adapted to jump to a location in the 
audio/visual bit stream, and may itself correspond to or be invoked by a 'next chapter up', 'previous chapter', 'play', 
'next index', or 'previous index' command. 

[0217] The command may be adapted to cause the or a further audio/visual bit stream to be stored. Thus flexibility 
can be achieved by combining commands to reproduce a bit stream with the ability to store (preferably to record) the 
40 or a further bit stream. 

[0218] In a related aspect of the invention there is provided a command for controlling the transfer of an audio/visual 
bit stream, the command adapted to invoke at least one command as aforesaid (including, particularly, the commands 
which invoke further commands). 

[0219] Despite providing up to three levels of abstraction or more, this has been found pursuant to the present in- 

45 vention to provide the advantage of further computational simplicity. 

[0220] In particular, if the command corresponds to a user-selectable audio/visual control operation, each layer of 
commands can itself be relatively simple, and have a relatively simple interface with the layers above and below, and 
yet cause sophisticated low-level actions to occur in response to a single high-level user (or other) request. 
[0221] In a further aspect of the invention, there is provided a method of controlling the transfer of an audio/visual 

50 bitstream, comprising comparing a command as described herein to a control criterion, and generating a further com- 
mand in dependence upon whether the command matches the control criterion. 

[0222] Thus, invalid or undesired commands or sequences of commands may be amended, or default commands 
may be substituted in their place. 

[0223] Preferably, the further command is compared to the control criterion, and the further command is then amend- 
55 ed in dependence upon whether it matches the control criterion. 

[0224] The comparison between the further command and the control criterion, and amendment of the further com- 
mand may be repeated, either up to a maximum number of repetitions or indefinitely, until a further command is gen- 
erated which matches the control criteria. 
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[0225] Preferably, the control criterion is dependent upon a characteristic of the transfer of the audio/visual bitstream, 
preferably of the transfer occurring at the time of receipt of the command. 

[0226] Thus, greater control over the transfer of an audio/visual bitstream may be obtained upon receipt of sequences 
of commands, or upon receipt of commands which specify operations which are relative to a current characteristice of 
5 the transfer of the audio/visual bitstream. 

[0227] For instance certain sequences of commands, or operations on a bitstream, which are not allowed or which 
are undesirable may be detected and replaced. 

[0228] For instance it may not be allowed to jump to a point in the bitstream and then fast forward, and a command 
to fast forward may be replaced by a command to play if it is received immediately after a command to jump to a point 
10 in the bitstream 

[0229] Other commands may be relative to a current characteristic of the transfer of the audio/visual bitstream. For 
instance, a command may specify jumping forward to a position relative to the current position. The acceptability of 
this command may be dependent both upon the command itself and the current position. 

[0230] Preferably, the characteristic of the transfer of the audio/visual bitstream is a transfer speed and or a position 
15 in the bitstream. 

[0231] Preferably, the control criterion is dependent upon conditional access and or parental control data. 

[0232] In a further related aspect of the invention, there is provided an operating system, comprising at least one 

command as aforesaid. 

[0233] In another aspect of the invention, there is provided a receiver/decoder, comprising at least one command 
20 as aforesaid. 

[0234] In a yet further aspect of the invention, there is provided a receiver/decoder, adapted to invoke at least one 
command as aforesaid. 

[0235] In another aspect of the invention, there is provided a computer program product, comprising at least one 
command as aforesaid. 

25 [0236] In a further aspect of the invention, there is provided a computer readable medium, comprising a computer 
program product as aforesaid. 

[0237] In another aspect of the invention, there is provided a signal, tangibly embodying a computer program product 
as aforesaid. 

[0238] In a further aspect of the invention, there is provided apparatus for processing audio/visual data, comprising 
30 means (such as an input) for receiving audio/visual data, means (such as an output) for outputting audio/visual data, 
and means (such as a processor and associated memory) for executing at least one command as aforesaid. 
[0239] In a related aspect of the invention, there is provided apparatus for processing audio/visual data, comprising 
an input, an output, and a processor and associated memory, the processor being adapted to execute at least one 
command as aforesaid. 

35 [0240] In another aspect of the invention, there is provided an audio/visual processing device, comprising apparatus 
as aforesaid. 

[0241] In another aspect of the invention there is provided a broadcast system, comprising a receiver/decoder as 
aforesaid. 

[0242] In a further aspect of the invention there is provided a method of controlling the transfer of an audio/visual bit 
40 stream, comprising invoking a command to set the transfer speed, and passing the transfer speed as a parameter to 
the command. 

[0243] In another aspect of the invention there is provided a method of controlling the transfer of an audio/visual bit 
stream, comprising invoking a command to set a position from which reproduction is to take place, and passing the 
position as a parameter. 

45 [0244] The invention extends to methods and/or apparatus substantially as herein described with reference to the 
accompanying drawings. 

[0245] Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate 
combination. In particular, method aspects may be applied to apparatus aspects, and vice versa. 
[0246] Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. 
so Any reference to software and hardware features herein should be construed accordingly. 

[0247] Preferred features of the present invention will now be described, purely by way of example, with reference 
to the accompanying drawings, in which:- 

Figure 1 is an overview of a satellite digital television system; 
55 Figure 2 is an overview of a cable digital television system; 

Figure 3 is an overall system view, with the head-end shown in more detail; 
Figure 4 is a schematic of the component architecture of the receiver/decoder; 
Figure 5 is a diagram of the software architecture of the receiver/decoder; 
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Figure 6 is a diagram showing the top half of Figure 5 in more detail; 

Figure 7 is a diagram showing the bottom half of Figure 5 In more detail; 

Figure 8 is a diagram showing an alternative embodiment of the bottom half of Figure 5; 

Figure 9 is an overview of a content management and protection system; 
5 Figure 10 is an alternative arrangement of the content management and protection system; 

Figure 11 is an illustration of the software architecture of the content management and protection system; 

Figure 12 is an illustration of the recording of encrypted content to a mass storage device; 

Figure 13 is an illustration of the playback of encrypted content from a mass storage device; 

Figure 1 4 is a graph of bitrate versus time for a variable bitrate bitstream; 
10 Figure 15 is a schematic illustration of an MPEG-2 bitstream as a function of time; 

Figure 16 is a representation of data offsets, with corresponding bitstream time offsets, for a file containing a 

representation of a variable bitrate bitstream; 

Figure 17 is a schematic diagram showing the correspondence between points in a bitstream and points in a file 
comprising a representation of the bitstream. 
15 Figure 1 8 is a schematic diagram illustrating searching for a point in file using HDVR indices; 

Figure 1 9 is a schematic diagram illustrating a fast-forwarding operation comprising skipping between periodically 
spaced points in a bitstream; 

Figure 20 is a schematic diagram illustrating a fast-forwarding operation comprising skipping between periodically 
spaced points in a bitstream, and locating the closest following key frames to these periodically spaced points; 
20 Figure 21 is a graph of bitrate versus time for a variable bitrate bitstream, showing portions of a bitstream above 

a selected value; 

Figure 22 is an illustration of the interpolation of HDVR index points upon recording; 

Figure 23 is an illustration of a discrepancy between HDVR index information and inserted ECM sections; 

Figure 24 is a schematic diagram of part of a file, including an Hfmd section; 
25 Figure 25 is an overview of the flow of data between the CM PS and the HDVR in a preferred embodiment; 

Figure 26 is an illustration of the structure of a typical bit stream; 

Figure 27 is a diagram showing an estimation process as described herein; 

Figure 28 is a further diagram showing the estimation process; 

Figure 29 is a yet further diagram showing the estimation process; 
30 Figure 30 is a schematic of the bit stream recording process; 

Figure 31 is a schematic of the bit stream playback process; 

Figures 32 are an illustration of filtering a sinusoidal bit stream using a rapid filter; 

Figures 33 are an illustration of filtering a sinusoidal bit stream using an inertia! filter; 

Figures 34 are an illustration of filtering a sinusoidal bit stream using a hybrid filter; 
35 Figures 35 are an illustration of filtering a sinusoidal bit stream using a static filter; 

Figures 36 are an illustration of filtering a constant bit rate bit stream using a hybrid filter; 

Figures 37 are an illustration of filtering a triangular bit stream using a hybrid filter; 

Figures 38 are an illustration of filtering a top hat bit stream using a hybrid filter; and 

Figures 39 are an illustration of filtering a peak in a bit stream using a hybrid filter. 
40 Figure 40 is a schematic of a personal video recorder system; 

Figure 41 is a schematic of three layers of commands for a personal video recorder system; 

Figure 42 is an illustration of a conventional fast-forward operation; 

Figure 43 is an illustration of a first alternative fast-forward operation; 

Figure 44 is an illustration of a further fast-forward operation; 
45 Figure 45 is an illustration of a first rewind operation; 

Figure 46 is an illustration of a further rewind operation; 

Figure 47 is an illustration of a slow-play operation; and 

Figure 48 is an illustration of an alternative slow-play operation. 

50 System overview 

[0248] An overview of a digital television system 500 is shown in Figure 1 . As will be discussed below, the system 
500 comprises a broadcast centre 1000, a receiver/decoder 2000, a software/hardware architecture 3000 of the re- 
ceiver/decoder, an interactive system 4000, and a conditional access system 5000, as will all be discussed below. 
55 [0249] The system 500 includes a mostly conventional digital television system 502 that uses the known MPEG-2 
compression system to transmit compressed digital signals. In more detail, MPEG-2 compressor 1010 in a broadcast 
centre 1000 receives a digital signal stream (typically a stream of video signals). The compressor 1010 is connected 
by linkage 1020 to a multiplexer and scrambler 1030. 
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[0250] The multiplexer 1 030 receives a plurality of further input signals, assembles the transport stream and transmits 
compressed digital signals to a transmitter 1010 of the broadcast centre via linkage 1022, which can of course take a 
wide variety of forms including telecommunications links. The transmitter 510 transmits electromagnetic signals via 
uplink 514 towards a satellite transponder 520, where they are electronically processed and broadcast via notional 
5 downlink 51 6 to earth receiver 51 2, conventionally in the form of a dish owned or rented by the end user. Other transport 
channels for transmission of the data are of course possible, such as terrestrial broadcast, cable transmission, com- 
bined satellite/cable links, telephone networks etc. 

[0251] The signals received by receiver 512 are transmitted to an integrated receiver/decoder 2000 owned or rented 
by the end user and connected to the end user's television set 10000. The receiver/decoder 2000 decodes the com- 
io pressed MPEG-2 signal into a television signal for the television set 10000. Although a separate receiver/decoder is 
shown in Figure 1 , the receiver/decoder may also be part of an integrated digital television. As used herein, the term 
"receiver/decoder" includes a separate receiver/decoder, such as a set-top box, and a television having a receiver/ 
decoder integrated therewith. 

[0252] In the receiver/decoder 2000 a hard disk 21 00 is provided, on which audiovisual and other data can be stored. 
15 This allows advanced recording and playback facilities for programmes received by the receiver/decoder, and also 
allows large amounts of other types of data, such as electronic programme guide data, to be stored in the receiver/ 
decoder. 

[0253] A content management and protection system (CM PS) 2300 (not shown) in the receiver/decoder provides 
the ability securely and flexibly to control the recording and playback of data on the hard disk 2100 (or other storage 
20 device). 

[0254] In a multichannel system, the multiplexer 1 030 handles audio and video information received from a number 
of parallel sources and interacts with the transmitter 510 to broadcast the information along a corresponding number 
of channels. In addition to audiovisual information, messages or applications or any other sort of digital data may be 
introduced in some or all of these channels interlaced with the transmitted digital audio and video information. 
25 [0255] An interactive system 4000 is connected to the multiplexer 1030 and the receiver/decoder 2000, and is located 
partly in the broadcast centre and partly in the receiver/decoder. It enables the end user to interact with various appli- 
cations via a back channel 570. The back channel may be, for example a Public Switched Telephone Network (PSTN) 
channel (for example, a modemmed back channel) or an Out of Band (OOB) channel. 

[0256] A conditional access system 5000, also connected to the multiplexer 1030 and the receiver/decoder 2000 

30 and again located partly in the broadcast centre and partly in the receiver/decoder, enables the end user to access 
digital television broadcasts from one or more broadcast suppliers. A smartcard, capable of deciphering messages 
relating to commercial offers (that is, one or several television programmes sold by the broadcast supplier), can be 
inserted into the receiver/decoder 2000. Using the receiver/decoder 2000 and smartcard, the end user may purchase 
commercial offers in either a subscription mode or a pay-per-view mode. Typically this is achieved using the back 

35 channel 570 which is used by the interactive system 4000. 

[0257] As mentioned above, programmes transmitted by the system are scrambled at the multiplexer 1030, the 
conditions and encryption keys applied to a given transmission being determined by the access control system 5000. 
Transmission of scrambled data in this way is well known in the field of pay TV systems. Typically, scrambled data is 
transmitted together with a control word for descrambling of the data, the control word itself being encrypted by a so- 

40 called exploitation key and transmitted in encrypted form. 

[0258] The scrambled data and encrypted control word are then received by the receiver/decoder 2000 having access 
to an equivalent to the exploitation key stored on a smartcard inserted in the receiver/decoder to decrypt the encrypted 
control word and thereafter descramble the transmitted data. A paid-up subscriber will receive, for example, in a broad- 
cast monthly EMM (Entitlement Management Message) the exploitation key necessary to decrypt the encrypted control 

45 word so as to permit viewing of the transmission, 

[0259] Figure 2 illustrates an alternative embodiment of a digital television system 504, utilising a cable network as 
the broadcast medium for the compressed digital signals. In this figure, like parts are indicated with like numerals. 
[0260] The satellite transponder and transmitting and receiving stations are replaced by a cable network 550. Addi- 
tional^ in this particular embodiment, the modemmed back channel between the receiver/decoder 2000 and the in- 

50 teractive system 4000 and conditional access system 5000 is removed, replaced by linkages 554, 556 between the 
cable network 550 and the conditional access system 5000 and interactive system 4000 respectively. The receiver/ 
decoder 2000 thus communicates with the other systems via the cable network 550, utilising a cable modem or other 
means to allow it to send and receive data via the same link as it receives data from the broadcast centre. 
[0261] The cable network 550 may be any form of wide area network (WAN), such as a dedicated connection, the 

55 internet, local cable distribution network, wireless connection, or any combination of the above. In the present embod- 
iment, the hybrid fibre coax (H FC) network is used. It is appreciated that the various means of communication between 
the receiver/decoder 2000 and the other components of the television system are interchangeable. 
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Conditional access system 

[0262] With reference to Figure 3, in overview the conditional access system 5000 includes a Subscriber Authoriza- 
tion System (SAS) 5200. The SAS 5200 is connected to one or more Subscriber Management Systems (SMS) 1100, 

5 one SMS for each broadcast supplier, by a link 1044, which may be a TCP-IP link or other type of link. Alternatively, 
one SMS could be shared between two commercial operators, or one operator could use two SMSs, and so on. 
[0263] First encrypting units in the form of ciphering units 51 00 utilising "mother" smartcards 5110 are connected to 
the SAS by linkage 1 042. Second encrypting units again in the form of ciphering units 51 02 utilising mother smartcards 
5112 are connected to the multiplexer 1030 by linkage 1040. The receiver/decoder 2000 receives a "daughter" smart- 

10 card 5500. The receiver/decoder is connected directly to the SAS 5200 via communications servers 1200 and the 
modemmed back channel 570. The SAS sends amongst other things subscription rights to the daughter smartcard on 
request. 

[0264] In variants of the preferred embodiment, internet or cable connections either complement or replace the PSTN 
570 and communications servers 1200. 
15 [0265] The smartcards contain confidential information from one or more commercial operators. The "mother" smart- 
card encrypts different kinds of messages and the "daughter" smartcards decrypt the messages, if they have the rights 
to do so. 

[0266] With reference to Figure 3, in the broadcast centre, the digital video signal is first compressed (or bit rate 
reduced), using the MPEG-2 compressor 1010. This compressed signal is then transmitted to the multiplexer and 
20 scrambler 1 030 in order to be multiplexed with other data, such as other compressed data. 

[0267] The scrambler generates a control word used in the scrambling process and included in the MPEG-2 stream 
in the multiplexer 1 030. The control word is generated internally and enables the end user's integrated receiver/decoder 
2000 to descramble the programme. 

[0268] Access criteria, indicating how the programme is commercialised, are also added to the MPEG-2 stream. The 
25 programme may be commercialised in either one of a number of "subscription" modes and/or one of a number of "Pay 
Per View" (PPV) modes or events. I n the subscription mode, the end user subscribes to one or more commercial offers, 
or "bouquets", thus getting the rights to watch every channel inside those bouquets. In the Pay Per View mode, the 
end user is provided with the capability to purchase events as he wishes. 

[0269] Both the control word and the access criteria are used to build an Entitlement Control Message (ECM); this 
30 is a message sent in relation with one scrambled program; the message contains a control word (which allows for the 
descrambling of the program) and the access criteria of the broadcast program. The access criteria and control word 
are transmitted to the second encrypting unit 5102 via the linkage 1040. In this unit, an ECM is generated, encrypted 
and transmitted on to the multiplexer and scrambler 1 030. 

[0270] Each service broadcast by a broadcast supplier in a data stream comprises a number of distinct components; 
35 for example a television programme includes a video component, an audio component, a sub-title component and so 
on. Each of these components of a service is individually scrambled and encrypted for subsequent broadcast. In respect 
of each scrambled component of the service, a separate ECM is required. 

[0271] The multiplexer 1 030 receives electrical signals comprising encrypted EMMs from the SAS 5200, encrypted 
ECMs from the second encrypting unit 5102 and compressed programmes from the compressor 1 01 0. The multiplexer 
40 1030 scrambles the programmes and transmits the scrambled programmes, the encrypted EMMs and the encrypted 
ECMs as electric signals to broadcast system 600, which may be for example a satellite system as shown in Figure 
1 , or other broadcast system. The receiver/decoder 2000 demultiplexes the signals to obtain scrambled programmes 
with encrypted EMMs and encrypted ECMs. 

[0272] The receiver/decoder receives the broadcast signal and extracts the MPEG-2 data stream. If a programme 
45 is scrambled, the receiver/decoder 2000 extracts the corresponding ECM from the MPEG-2 stream and passes the 

ECM to the "daughter" smartcard 5500 of the end user. This slots into a housing in the receiver/decoder 2000. The 

daughter smartcard 5500 controls whether the end user has the right to decrypt the ECM and to access the programme. 

If not, a negative status is passed to the receiver/decoder 2000 to indicate that the programme cannot be descrambled. 

If the end user does have the rights, the ECM is decrypted and the control word extracted. The decoder 2000 can then 
so descramble the programme using this control word. The MPEG-2 stream is decompressed and translated into a video 

signal for onward transmission to television set 10000. 

[0273] If the programme is not scrambled, no ECM will have been transmitted with the MPEG-2 stream and the 
receiver/decoder 2000 decompresses the data and transforms the signal into a video signal for transmission to tele- 
vision set 10000. 

55 [0274] The subscriber management system (SMS) 1 1 00 includes a database 1 1 50 which manages, amongst others, 
all of the end user files, commercial offers (such as tariffs and promotions), subscriptions, PPV details, and data re- 
garding end user consumption and authorization. The SMS may be physically remote from the SAS. 
[0275] The SMS 1 1 00 transmits messages to the SAS 5200 which imply modifications to or creations of Entitlement 
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Receiver/decoder 

.CL"*""" 9 '° '■ °" V, " 0 ' , ' "• ,, * n, • " ™=*»"*~* 20»0 w. »o» b. „.««,., in fc,™ ., , u „o. 

of Fig. 1 ), and switch contacts on the front panel 2054 of the decoder. cnannel 570 

supply -the necessary control word to a demuKiplexer/descrambler/remultipiexer unit 20 0T0 ena e ht enZed 
broadcast signal to be descrambled. The decoder also includes a conventional tuner 2016 and demodulato 20?2 to 

bier umt 2010. A second tuner 201 8 and second demodulator 2014 are also provided, to allow amoni^SZ 
a second channel to be received and decoded in parallel with the first amongst other things, 

bZVrJlTf Sk T °? fS alS ° Pr ° Videdi a "° Wing St0rage 0f P'^mme and application data received and generated 
by the receiver/decoder. In conjunction with the two tuners 201 6, 201 8, two demodulators 201 2 201 4 the descramb er/ 
demu lt, P exer/remul,, P lexer2010, and the data decoder2024 and audio decoder2026, advanced r^g^cZ. 
is beina a lrr:?: d 0V ' a " 0Wir : 9 SimU " ane0US recordi "9 s of - ™* Programmes while J££%££*L 
t^S^'^^^^^ " fr ° m ^ h3rd diSk ,0 and <™ «» ^ **~ -puts 

"^L™^ 10 ° UtPUt 2038 and Vid6 ° ° UtpUt 2040 ln the reiver/decoder are fed by the PCM mixer 2030 and 
aud.o DAC 2034, and the MPEG video decoder2028, graphic engine 2032 and PAL/SECAM ^encoder 2036^ ZSStSS 
Alternative or complementary outputs may of course be provided encoaer^ujb respectively. 

EL o?n U r S f m^! deSCr . iption * an *PP"«»Uon is preferably a piece of computer code for controlling high level 
2080 on a button object seen on the screen of the television set (not shown) and presses a validation key the instruct on 
□ro q ce s n s C o e IZ W ' th bUtt ° n " rU °- Application * -nd the associated middleware JZZZ££ES 

^^^STJTSST (RPCS) being made to the digital ™ c — 2004 ao ™" r 

SSflt t A " Tf. !f ' * application pr °P° ses menus executes commands at the request of the end user and pro- 

e ROM for FLASH SrMST" " Tn^*™- APP ' iCa,i0nS ™* ^ er -sident'appltcations, thatls stoS 
J* ram other non-volatile memory) of the receiver/decoder 2000, or broadcast and downloaded into 

the RAM, FLASH memory or hard disk of the receiver/decoder 2000 

K^M^'rf 0 " 8 are St0red in memor y locations in «"« receiver/decoder 2000 and represented as resource files 

Z^^z:*^r hic obiect description unitfnes ' variabies b,ock --I — se qU ence e ;:::; 

[0284] The receiver/decoder contains memory (not shown) divided into at least one RAM volume a FLASH volume 
and at least one ROM volume, but this physical organization is distinct from the logica. organST ^e memo™ mav 
further be divided into memory volumes associated with the various interfaces. From one p^n of vfewThe Tmo™ 

rU 9 f„ h 3 ? P V? thS hardWSre; from an0,her point of view ' the mem <"V ^n be regarded as supportrq o^ 
conta.ning the whole of the system shown apart from the hardware. supporting or 

Architecture of receiver/decoder 

[0285] With reference to Figure 5, the software/hardware architecture 3000 of the receiver/decoder contains five 
software layers, organized so that the software can be implemented in any receiver/decoder and wtth anv opera no 
system. The vanous software layers are application layer 3100, application programming interface ^ 
virtual machine ,ayer 3500, device interface .ayer 3700 (often abbreviated jus't ^device aye,) and £2JX2£ 
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hardware layer 3900. 

[0286] The application layer 31 00 encompasses applications 3120 that are either resident in or downloaded to the 
receiver/decoder. They may be interactive applications used by customers, written in, for example, Java, HTML, MHEG- 
5 or other languages, or they may be applications used by the receiver/decoder for other purposes, for example for 
running such interactive applications. This layer is based on a set of open Application Programming Interfaces (APIs) 
provided by the Virtual Machine layer. This system allows applications to be downloaded to the hard disk, flash memory 
or RAM memory in the receiver/decoder on-the-fly or on demand. The application code can be transmitted in com- 
pressed or uncompressed format using protocols such as Data Storage Media Command and Control (DSMCC), Net- 
work File Server (NFS) or other protocols. 

[0287] The API layer 3300 provides high-level utilities for interactive application development. It includes several 
packages that make up this high-level API. The packages provide all the functionality necessary to run interactive 
applications. The packages are accessible by the applications. 

[0288] In a preferred embodiment the API is adapted for applications written in the Java, PanTalk or such similar 
programming languages. Furthermore, it can facilitate the interpretation of HTML and other formats, such as MHEG- 
5. Besides these features, it also includes other packages and service modules that are detachable and extensible as 
requirements dictate. 

[0289] The virtual machine layer 3500 is composed of language interpreters and various modules and systems. This 
layer, managed by a kernel 3650 (not shown), consists of everything necessary to receive and execute interactive 
applications in the receiver/decoder. 

[0290] The device interface layer 3700 includes a Device Manager and software devices (generally referred to herein 
as just 'devices'). Devices are software modules which consist of the logical resources necessary for management of 
external events and physical interfaces. The device interface layer, under the control of the Device Manager, manages 
communication channels between drivers and applications and provides enhanced error exception checking. Some 
examples of managed (hardware) devices are: card readers 3722 (not shown), modems 3730 (not shown), network 
3732 (not shown), PCMCIA (Personal Computer Memory Card International Association), LED display and so on. 
Programmers do not have to deal with this layer directly, since the API layer controls the devices from above. 
[0291] The system software/hardware layer 3900 is provided by the manufacturer of the receiver/decoder. Because 
of the modularity of the system and because services supplied by the higher-level operating system (such as event 
scheduling and memory management) are part of the virtual machine and kernel, the higher layers are not tied to a 
particular real-time operating system (RTOS) or to a particular processor. 

[0292] Typically the virtual machine layer 3500, occasionally in combination with the device interface layer 3700 and/ 
or API 3300, is referred to as the 'middleware' of the receiver/decoder. 

[0293] With reference to Figure 6 the software architecture of the receiver/decoder 3000 corresponding to the top 
half of Figure 5 (comprising the application layer 3100, API layer 3300 and virtual machine layer 3500) will now be 
described in more detail. 

[0294] Interactive applications are applications that the user interacts with, for example, to obtain products and serv- 
ices, such as electronic program guides., telebanking applications and games. 

[0295] There are two types of application in the application layer 3100, plus the Application Manager 3110. There 
are interactive applications such as a Web Browser 31 30 which can be added at any time as long as they conform to 
the APi 3300, and there are resident applications which manage and support the interactive applications. The resident 
applications are substantially permanent and include the following: 

• Boot. The Boot application 3142 is the first application launched when the receiver/decoder is powered on. The 
Boot application first starts the Application Manager 3110, and then starts the "Manager" software modules in the 
virtual machine 3500, such as the Memory Manager 3544 and the Event Manager 3546. 

• Application Manager. The Application Manager 311 0 manages the interactive applications that are run in the re- 
ceiver/decoder, that is, it starts, stops, suspends, resumes, handles events and deals with communication between 
applications. It allows multiple applications to run at once, and thus is involved in the allocation of resources among 
them. This application is completely transparent to the user. 

• SetUp. The purpose of the Setup application 3144 is to configure the receiver/decoder, primarily the first time it 
is used. It performs actions such as scanning for TV channels, setting the date and time, establishing user pref- 
erences, and so on. However, the Setup application can be used at any time by the user to change the receiver/ 
decoder configuration. 

• Zapping. The Zapping application 3146 is used to change channels using the Program-up, Program-down and 
numeric keys. When anotherform o( zapping is used, for example, through a banner (pilot) application, the Zapping 
application is stopped. 

• Callback. The Callback application 31 48 is used to extract the values of various parameters stored in the receiver/ 
decoder memory and return these values to the commercial operator via modemmed back channel 1070 (not 
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shown), or by other means. 
[0296] 



ages 3320, and proprietary packages 3330 used , , T° fe8tUreS °' the Virtual machlne . DAVIC pack- 
software vendor * P 9 3 °' USed '° aC ° eSS ,eatures of the softw ^ architecture unique to the principal 

[0298] Considered in more detail, the virtual machine 3500 includes the following: 

' SS^S^ *> - 'Vpe °< a PP«ca«ons to he 

preters 3518 and others merPrelerS 3512 ' PanTalk "«erpreters 3514, HTML interpreters 3516, MHEG-5 inter- 

* mJ^&szz sasfrr-:— t video Bro — 

tables by applications which need the data contained in them ° WS aCC6SS l ° theSe 

' e'vttTeuf 42 - ™ S m ° dU ' e ^ ^ » aded — **0 with each thread having tts own 

* SinTaX,^ 

; a™ s Sfol«^ — — — - 

SESSSS^^T^ '° adS ° laSSeS ^ reS °' VeS a " y C,as ' referenci "9 P-Wm. 

' P^T^ frama ~ D£ ^C carouse, or through the NFS 

authentication are aiso provided 6 ^ 38 reS ' dent ° n6S ' cle *™P> compression and 

[0299, Furthermore, the DAViC resource notification mode, is supported so that Cent resources are efficiency man- 

fSyer A 370orot snoTn)^ e^T^ZT^ T? * "" ^ maChi " e 3500 and davi ~ ^e, 
standard for operating systems " reaS ° nS ' the k6mel im P'*™nts relevant parts of the POSIX 

responding provisions, such as requiring Thread IDs to ToZ fa 2 „. , 3850 (n0t Shown) - Cor - 

ssrs°° to f ,ow ■? ^ a «--i h 2 r raszsrr 1 are a,so made in the 

Sed tor SS, ' h 'reel SjL^XS Sonfof'th T -T ^ ^° VR) ™ M 3850 

component. The ^comprtJ^^SSHS^IS htn, 221 ^ 0,her attaCh6d maSS stora S e 

srr a fi,e system ,Lary 3852 for ^^^^^x"sr thread 3858 ,or hand,in9 

— * - hard L vid P o reader ( HOV R) 3850 rece.es 
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thread also interacts with the file system library 3852 to coordinate the recording or playback operation at appropriate 
places on the hard disk 221 0 (not shown). 

[0306] The file system library 3852 then sends commands to the mass storage device 3728 (also shown in Figure 
7) which tell the mass storage device 3728 which sub-transport stream (STS) to transfer (via a FIFO buffer), and on 

5 which hard disk target the stream should be stored. Allocation of clusters on the hard disk and general file management 
is carried out by the file system library 3852, the mass storage device itself being concerned with lower level operations. 
[0307] The service device 3736 mentioned above is unique amongst the devices in that it does not relate to a physical 
component of the receiver/decoder. It instead provides a high level interface which groups together in a single 'instance* 
the various sets of tuner, demultiplexer, remultiplexer and hard disk devices in the receiver/decoder, freeing higher 

10 level processes from the difficulties of coordinating the various sub-devices. 

[0308] With reference to Figure 7 the software architecture of the receiver/decoder 3000 corresponding to the bottom 
half of Figure 5 (comprising the device interface layer 3700 and the system software and hardware layer 3900) will 
now be described in more detail. 

[0309] Further devices provided in the device layer include the conditional access device 3720, tuner devices 3724 
15 corresponding to the two (or potentially more) tuners 201 6, 201 8 of Figure 4, the video device 3734, the I/O port device 
3726, and the service device 3736 and mass storage device 3728 mentioned above. 

[0310] In broad terms, a device can be regarded as defining a logical interface, so that two different devices may be 
coupled to a common physical port. Certain devices may communicate among themselves, and all devices also operate 
under the control of the kernel 3650. 

20 [0311] Before using the services of any device, a program (such as an application instruction sequence) has to be 
declared as a "client", that is, a logical access-way to the device or the device manager 3710. The manager gives the 
client a client number which is referred to in all accesses to the device. A device can have several clients, the number 
of clients for each device being specified depending on the type of device. A client is introduced to the device by a 
procedure "Device: Open Channel". This procedure assigns a client number to the client. A client can be taken out of 

25 the device manager 371 0 client list by a procedure "Device: Close Channel". 

[0312] The access to devices provided by the device manager 3710 can be either synchronous or asynchronous. 
For synchronous access, a procedure "Device: Call" is used. This is a means of accessing data which is immediately 
available or a functionality which does not involve waiting for the desired response. For asynchronous access, a pro- 
cedure "Device: I/O" is used. This is a means of accessing data which involves waiting for a response, for example 

30 scanning tuner frequencies to find a multiplex or getting back a table from the MPEG stream. When the requested 
result is available, an event is put in the queue of the engine to signal its arrival. A further procedure "Device: Event" 
provides a means of managing unexpected events. 

[0313] In a second embodiment of the receiver/decoder, the lower half of the architecture of the receiver/decoder is 
replaced by the layers shown in Figure 8. 
35 [0314] In this embodiment, an extended device layer interface (EDLI) 3600 is provided between the virtual machine 
3500 (not shown) and the device interface layer 3700, and an abstraction device interface 3800 is provided between 
the device interface layer 3700 and the system software/hardware layer 3900. Otherwise, like parts are indicated with 
like reference numerals. 

[0315] The extended device layer interface (EDLI) 3600 provides a dedicated interface between the virtual machine 
40 3500 and the device interface layer 3700 and generally provides multithreading support to the device interface layer. 
Functions of the EDLI include routing asynchronous events to the appropriate thread in the middleware (since the 
device interface layer need not itself support multithreading) and routing messages between threads. 
[0316] The abstraction device interface 3800 provides a further interface between the device interface layer 3700 
and the device drivers 391 0 in the system software/hardware layer 3900. By providing such an interface, the large and 
45 complex device layer 3700 can be made hardware independent to a greater degree. 

Content management and protection system (CMPS) 

[0317] With reference to Figure 9, the content management and protection system (CMPS) 2300 mentioned above 
50 is distributed between the broadcast centre 1 000 and the receiver/decoder 2000. The receiver/decoder component of 
the CMPS is provided in the form of a smartcard with associated smartcard reader, but in variants of the preferred 
embodiment is implemented solely in software or in otherforms of hardware. The CMPS can ensure that only authorized 
users can record and playback content, in accordance with predefined usage rules. 

[0318] An important part of the content management and protection system is the special Usage Rules Message 
55 (URM) which contains content management information relating to a given programme or transmission and is trans- 
mitted before such a programme or transmission. In essence, the Usage Rules Messages impose usage constraints 
on the playback and reproduction of the content, and can be directed only to specific portions of the content, such as 
separate 'chapters' within a programme, or to the content as a whole. Typical usage rules include restrictions on time- 
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management message (EMM, or CAS EMM) Jerr^ot^l h Z * '° ,he conditional a <*«" entiUement 
ocal storage of programme data ratherlhan broaS laramm/1? ™smltted access rights relate to the 
[0320J In the preferred embodiment shownTn o 9 th , ' 38 m * the ,conve n«<>nal' EMM. 

» EMMs 5614 and URMs 5612, rZXxS ZnSZZ L,* mM,p,eXer and sc ^bler 1030 receives the CMPS 
data) 810 and broadcasts the JS^SS^^SZ SSHS*? "T^" C ° ntent < Pr °» a 
then receives the scrambled content 800, and removes and ^J^L ^Z l 8 ^ 600 The reca 'ver/decoder 
and conditional access system 5000 as approprX PS EMMs and URMs to the c ^ 2300 

CMPS smartcard (not shown) to allow the URMs , 0 be dec^pteT " * ,he rece 'ver/decoder 

can have the same structure as conventil^ J^S?^^^ ™ M .»^^ EMMs 
embeds a key associated with a content or service Rights to IvbT^ I „ „ ey -° r,enled " a CMP_EMM typically 
off payments (impulse purchases) or subscripts Various leS, of rec0rded content ™ Slanted in return for one- 
any content, whereby a user could, for exampte pay a fi^t ee in llc^ Tl! ^ a ' S ° be 9ran,ed in re,ation *° 
pay a second, higher, fee in return for unlimited epZ CMP EMM l ** ?' °" '° r6play Content °' 
smartcard, bu, may be stored eh^ n !ST^i^^y^^ St ° red in ,he -ceiver/decoder CMPS 
[0323J In the preferred embodiment riAhte t„ , con °H>onal access smartcard, for example, 
(the 'pay-per-view' mode.) * 2^! ZZTV*? ^ ° btM after tha r «9 - made 

conversely one could be unable to view a Z_ h , W a P roaramme °"t not record it and play it back, and 
Play it back. W 3 pro 9™^ bu < °™ could record it, obtain the necessary rights and then 

en.ly to a receiver/decoder 2000, from a rst pa,lv -00 f™ * ' ? o * ( URM " ) 9rS a " delivered inde P a ^" 
third party may be, for example, a mum ^ Vwi^SS* ?* T* ™ 1204 " ThS ,irSt ' Second « 
and URMs 561 2 may be delivered Typically awe ™!! r * ,T SCramb,ed content 130 °. CMPS EMMs 5614 
("CONTENT") to the multiplexer/s^ 

transmitted to the receiver/decoder 2000 in the u "u ai fashion (CONTENT*) is generated and then 

Sd. Wl,h ref6renCe 10 Fi9Ure 11 ' the atlon of the CMPS at the receiver/decoder 2000 wil, now be de- 

KUs^rn^ 

indirectly with the HDVR controller 3350 The C " S s ver mooSe taoT ° MPS ^ 3362 ' 9nd in,erfaces 

then routed to the CMPS smartcard alonawi I 'smartcard. Control words 5600 derived from the ECMs are 
also received in the program^ 

bines and encrypts the three items tfda J tin , mTalme' t T" ^ CMPS SmartCard < hen ™ 

to the CM PS core for further processing In resp • ZotZT ^ <CMMS) WhiCh arS then P assed 

controller 3350 so that they can be stored on pi' ' ' ] ZZZ ST „' ^ "* ^ P3SSed t0 ,he HDVR 

[0329] In the process of recording content to e i" ■* ™ tho ' orres P°nd.ng content data. 

stage 5550 in the conditional acces's "martc d ■ 'ml T s d^ed? ^ "* 5602 ' S ^ l ° 3 ^P" 0 " 
decrypted control word 5600 then passes to an ^S^TZ^JSS^ TJStZ 
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into a content management message (CMM) with the corresponding URM 5612 and CMPS EMM 5614, and then re- 
encrypted as a whole using a local exploitation key KL 5608. The CMM is then stored in a separate file 2112 to the file 
2110 used to store the unaltered, scrambled content in the hard disk 21 00. 

[0330] In the reverse process of playing back content from disk, illustrated in Figure 1 3, the scrambled content 1300 
5 is read from the file 2110 on the hard disk 2100 and fed into the descrambler 2010. In parallel, CMMs are read from 
the separate file 2112 and fed into a decryption stage 2204 in the CMPS smartcard. The CMMs are decrypted with the 
local exploitation key 5608 and then split into the URM 5612, CMPS EMM 5614 and control word 5600. If the CMPS 
module decides that the user is entitled to view the material (on the basis of the URM and CMPS EMM), the control 
word 5600 is then sent to the descrambler 2010 at the appropriate time to allow the content to be descrambled. 

10 

INTERNAL FORMAT 

Variable bitrate bitstream transmissions 

15 [0331] Transmissions received, processed and stored by the preferred embodiments are in the form of bitstreams, 
and the retrieval and processing of data from recorded bitstreams is dependent in part upon the characteristics of such 
bitstreams. The use of table of records, in particular HDVR and USER indices in particular embodiments, in such 
recordal and processing, particularly of files containing recordings of variable bitrate bitstreams, and the synchronisa- 
tion, storage and retrieval of encryption information related to such files is described later. At this point the general 

20 characteristics of variable bitrate bitstreams are discussed briefly. 

[0332] Figure 14 is a graph of bitrate versus time for a satellite TV transmission. 

[0333] In various embodiments, variable bitrate bitstreams similar to those illustrated in Figure 1 4 are received, trans- 
mitted and stored in or between computer devices, processors, A/D convenors, televisions, HDVRs, or storage devices 
for instance hard disks, tapes, computer storage devices, CDS, or DVDs. Such variable bitrate bitstreams include data 
25 in a variety of compression formats, including MPEG-2, MPEG-4, MP3 protected by different ciphering algorithms 
including DVB-CS, DES, 3DES, and contain video and or audio data, teletext information, subtitles, any other type of 
text information, computer data, or representations of such data. 

[0334] Figure 15 is an illustration of an MPEG-2 data stream as a function of time, showing schematically the position 
of key frames known as Intraframes (l-frames) 4500 and 4502, and delta frames in the form of B-frames, for instance 

30 at 451 0, and P-f rames, for instance at 451 2 within the bitstream. The key frames can independently be used to regen- 
erate a portion of audio/visual data, whereas the delta frames map changes from other frames and can be used to 
regenerate a portion of audiovisual data only in dependence upon such other frames. An interframe (P-frame) maps 
changes from the preceding frame, whereas a B-frame maps changes from either or both preceding and following 
frames. In MPEG-2 data streams, key frames are usually transmitted with a frequency of 2Hz. 

35 [0335] Upon reception, the bitstream is generally stored as a data file in a data storage device, unless it is played 
out or retransmitted immediately without being stored. A data file 6000, including the correspondence between time 
offset in a bitstream 6002 and data offset in the data file is shown in Figures 16 and 1 7. 
[0336] Further detail is now provided with respect to three general aspects of preferred embodiments:- 

40 - the generation and use of index tables in the retrieval and processing of stored bitstreams 

the estimation of position in a bitstream, and the synchronisation of conditional access information with the bit- 
stream 

command sets for controlling the transfer of a bitstream 

[0337] Beginning with the generation and use of index tables in the retrieval and processing of stored bitstreams, 
the structure and content of stored bitstreams, in the form of files stored by an HDVR, are first examined. 

Structure of HDVR files 

so [0338] Looking at the structure of stored data in more detail, HDVR files comprise both management data (referred 
to in the following as hdvr_managemenLdata) and content data (referred to in the following as hdvr_content_data). 
The management data and the content data are stored at the HDVR either as separate parts of the same file, or as 
separate files. 

[0339] The hdvr_content_data comprises a stored transport stream (STS), which is discussed in more detail below. 
55 Firstly, however, the hdvr_management_data is examined in more detail. 

[0340] The hdvr_management_data comprises CMMs as described above (typically in the form of a dedicated two 
dimensional table), and typically also comprises the following tables:- 
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Index table 
Chapter table 
Private PMT table 
Parental Control Data table 
Maximum Values table 
General Information table 



[0342] in p« erlM th . HDVR ■»,„ aM oomplB , s . 

- firstly, the General Information table 

- secondly, the Maximum Values table 

- thirdly, other HDVR tables, such as Private PMT tables, Chapter tables. 

»-™^^^^ 

HDVR index table and operations performed by the HDVR on a recorded bitstream 

CLI^ one time offset (i „ seconds, divided into cryp- 

the bitstream is a variab.e bitrate bi-^T.°25S previously 9 ' rePreSentati ° n °' the bitStrea - 

si zioS:^:^^^^ the c h MM j ndices and have a — d - «™ * 

index tabie can be used to look upThe fL offset positton wftl re ST ?° W ° 9 ,h ° ^ " Umber ' the HDVR 
the need for potentially time-consuming binarysearch no ZT ".T SeC ° ndS ° f WP****. *»hout 
in bit rate. The change in time is the ?ime Seen saX a,a0rlthms whlch with a change 

V « a — P-^g bitstream. and 

in the HDVR index table. QeneX^i^S^r^? 9 * USe ° f HDVR and USER indices stored 
are inserted upon command of a user automatical, y b V HDVR, and the USER indices 

KL;L^ J*, tab, is stored in the 

stored in a separate file, or in other locations within an HDVR fife ' embedments, an HDVR index table is 

p'ji^ztzitz set h itz:z% in the ^-r-™*^-*** p art 0 , . HDV r » h 

hdvrjne management da ta and eyries in L indJv^h '"""^ion is stored as a CMM table in 

points in an HDVR flielndexeo by XS^^SJKZ Zh h° '7? ** ° MM ^ S ° that data at 
CMM table. SER md ' CeS may be d «=°ded using corresponding entries in the 

of a programme. ' rther SUCh table ' ls 9 ener ated upon command after recordal 

HDVR indices 
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[0354] In preferred embodiments, the HDVR indices are generated and stored in real time during the recordal of a 
programme. A recording comprises no more than MaxHdvrlndexNumber indices. 

[0355] The HDVR indices are generally positioned at periodic time offsets in the bitstream. In preferred embodiments, 
the bitstream comprises data compressed according to the MPEG-2 protocol and according to this protocol key frames, 
5 known as intraframes, are located every 0.5 seconds in the bitstream. As described above, such key frames may be 
used to regenerate a portion of audiovisual data, for instance a frame in a film, independently of other portions of data 
in the bitstream. The HDVR indices in such embodiments have time offsets which are distributed with a period of 0.5 
seconds, and the indices correspond to the beginning of each key frame. 

[0356] In variants of the preferred embodiments, the HDVR indices are positioned with time offsets with different 
10 periods, and in some variants such periods are varied both upon command of the user, and automatically by the HDVR. 

USER Indices 

[0357] The USER indices are positioned by the client and are also play entry points. As mentioned above, the play 
15 granularity is the HDVR index, and in preferred embodiments the user indices are based on these HDVR indices. It is 
straightforward to recover using the HDVR indices, the CMM applicable to the USER index by CMM family. 
[0358] The USER indices are set at the time of recording of a programme or playback of a recorded programme. In 
particular embodiments the number of such USER indices is limited, and a recording comprises no more than MaxU- 
serlndexNumber indices. 

20 [0359] In preferred embodiments, the bitstream comprises MPEG-2, MPEG-4 or MP3 data, although in other em- 
bodiments the bitstream may comprises data in a variety of other compression formats. 

Bitstream operations using HDVR and USER indices 

25 [0360] The HDVR and USER indices are used to perform a variety of operations on the STS. 

Searching 

[0361] For instance, as illustrated in Figure 18, the HDVR and USER indices are used to find preferred points in an 
30 HDVR file 6300, corresponding, for instance, to preferred time offsets in a corresponding bitstream. The closest point 
6310, or more usually the closest preceding point 6312, in the file to the preferred point 6314 is located in an Index 
table 631 6 of HDVR and USER indices, by the HDVR, and the fiie is searched from this point by the HDVR to find the 
preferred point. Generally, the searching is performed by decoding (for instance using corresponding entries in a CMM 
table) and reading data from the indexed point onward until the preferred point is found. In some variants indexed 
35 points correspond to preferred points, and in such variants a search is performed merely by jumping to the appropriate 
indexed point. 

[0362] In alternative embodiments, if a preferred point which is the subject of a search falls between points in the 
file referenced by two HDVR or USER indices, the file is searched from a point intermediate between the two indexed 
points. This intermediate point is located by linear interpolation between the two indexed points. In variants of such 
^0 embodiments, the intermediate point is located by using other data interpolation techniques or by fitting indexed points 
to alternative functions, such as polynomial or exponential functions, or cubic spline functions. In such variants, further 
indexed points in addition to the two indexed points adjacent to the preferred point are used to locate the intermediate 
point. 

45 Trick mode operations 

[0363] In preferred embodiments, HDVR indices correspond to periodically spaced points in time in a bitstream. 
"Trick mode" operations, such as fast forwarding and rewinding, are performed by the HDVR, by locating, using the 
HDVR indices, decoding, and displaying data in a file corresponding to such periodically spaced points in time in a 
so bitstream. 

[0364] The speed of, for instance, rewinding or fast forwarding is varied in preferred embodiments by varying the 
rate at which the stored bitstream is played back. Typically, not all of the bitstream data is played back during a rewinding 
or fast forwarding operation, but rather selected portions, usually equally spaced in time in the bitstream, are played 
back. The rate at which data is read from the file can be varied for any particular rewinding or fast forwarding speed 
55 by varying the proportion of data in the bitstream which is played back. In preferred embodiments, the speed of re- 
winding or fast forwarding is varied upon command of a user. 

[0365] By way of example, a fast forwarding operation is illustrated in Figure 19. The HDVR locates using HDVR 
indices, decodes, and displays data at points in a file corresponding to equally spaced points in time 6400, 6404, 6408 
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points 6400, 6404, 6408, and 6412 are d^^!^^S!lH^^?T^ 8 ^ ,W8 * e ^ M ^ ,< *»»«»to^ 
[0366] In preferred embodiments ViSS^IKSS 2* P °' ntS Wh,Ch are se,ected 

key frames (.-frames in the case of MPEG 2) wh^h can be us J it £Z t "Z* ' ndi ° eS ^ * b ° 9 ' mnm ° ot 
data independently of any other portion of date AooTvTa Ra^V*?T POrt '° nS °'' in particu,ar ' «^io/visual 
ooinoide with at least some of the HDVR indS locations 631 2 M ° * VariantS ' '° Cati ° nS ° f ,rames 
by locating key frames in a file located a equafly spaced time LeSi T„« ? a " d reWlndln 9 is P erf °™ d ^ 
looking up the HDVR indices. intervals or offsets ,n the corresponding bitstream by 

[0367] In variants ofthe preferred embodiments, the HDVR indices orUdFRm^o m . 

to key frames. As illustrated in Fiqure 20 indie** 2tJ~Z2!? « Ces> do not nece ssarily map directly 

and 6522 in the bitstream, a I^i^S ^ 65 ° 4 ' ^ 651 °' 6512 ' 6516 ' 6518 
frames are .ocated at time offsets 650 ,6508 6514 and 6520 ?„ Te h ?? ' T T^ 0 " ° f bitStreanr Ke * 
frames are located at corresponding data offseis In the am tna bltstream < and representations of these key 

[0368] Figure 20 also illustrates a ^fas SoSi n nno r l " C " CeS d ° not reference these ^e offsets, 

indices, points in the file corresoondi rJZZZZZZ^?™" embodiment. The HDVR locates, using the 
and 6522 which are also referenced by HDVR ndS ™ ^sk^f/nn b ! ,Stream - P ° intS 65 ° 4 ' 651 °' 651 6 - 

to 6500, the HDVR decodes the data in the fite a ml ■ * P ^ ° f ,he P ° int ,he fi,e "responding 

proceedsto decode thefollowng data ISlTi7 ft8 ^ CMM,ramtoCHMI *M^ 
The key frame is then displayed" by a difpfay de^ce Sed Z^SSSS^SS' 6502 the brtS,ream - 

file corresponding to 6506,651 2 and 651 8 and to Z-Z hV ° VR P roceeds t0 lo ««e points in the 

key frame are displayed on the di^ dev^ " ,££2" *" tam# at 65 ° 8 ' 651 4 ' and 6520 ' ^ 

5e ZTcvX^T^ ref6renCe P ° intS 3 bitStream ' and —ponding points in a file, which coincide 

Salels^^ iS St ° red °" a DVD ^ a «— - in^ces mapping 

indices correspond to periodica!y ?pa2d plt!^^T °" T* ^ AS ^ the HDVR *^°«™ent the 
stored in thetab^^ 

Performance of trick mode operations .n dependence upon hardware character.st.es 

write hard disk access time, parsing demultiplexer bandwlX , " Particular dependent upon read/ 

fast forwarding or rewindMq soee ^tToSjZZ f SUCh maxi ™ m ,rame *». and with the requested 

in both cases, as the time taken to display t^^^^^^^^'^^ speed is the sa ™ 

* a stored bitstream in c^ 

SoVRTnrivS 

is not varied, and in s"h^ 

Automatic generation of Index tables in dependence upon bitstream characteristics 

[0376] In preferred embodiments indices, such as USER indices and HDVR indices, are created or deleted auto- 
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matically in dependence upon analysis of characteristics of bitstream data by a processor. For instance, in one variant 
such a processor included in an HDVR creates indices corresponding to portions of a bitstream where the bitrate is 
within a particular range of values. Such values can be set by operation of a user-defined algorithm. 
[0377] By way of example, in one variant, as illustrated in Figure 21 , indices are created at points where the bitrate 
5 rises above a particular value 6600, set by a user. The portions of the bitstreams commencing at these points may 
correspond, for instance, to an action sequence in a film. In further variants, the processor is programmable, and the 
dependency upon analysis of characteristics of bitstream data can be varied. 

[0378] In further variants, a processor analyses user actions and creates or deletes indices, including USER indices 
and HDVR indices, in dependence upon this analysis. The processor is programmable and this dependency can be 
10 varied. In one example of such dependency, more indices are created corresponding to points in a bitstream upon 
which a user is performing a large number of actions. 

[0379] In further variants, data is inserted upon the command of the user into a table, or into an associated table or 
file, and this data Is associated with particular data offsets or associated time offsets referenced by USER indices, or 
HDVR indices. Such data includes comments to be displayed on a screen, and commands, such as television control 
15 commands, and in particular includes data which activates or deactivates a parental control mechanism. Such parental 
control mechanism is generally directed to particular chapters, but in certain variants it is also directed to cryptoperiods 
and pluralities of cryptoperiods, and user defined portions of a file. In some such variants a user can select particular 
scenes within a recorded film to which they wish to control access. 

20 Output data 

[0380] Generally, data located in an HDVR file using the HDVR and USER indices is decoded, for instance using a 
CMM table as described above, and decompressed, if it is subject to a compression protocol such as MPEG, and is 
output to a display device, generally a TV screen. However, in certain embodiments, such data can atso be output to 
25 a mass storage device, or to a processor, with or without being decoded or decompressed. 

[0381] Further detail is now provided concerning the structure and generation of index tables, and the use of index 
tables in playing back encrypted content. 

[0382] HDVR and USER indices are stored together in the same table referred to as an index table, lndex_Tabte(), 
as discussed above. 

30 [0383] The HDVR part of the index table is a one-dimensional array of temporally periodic successive HDVR index 
descriptors. 

[0384] Each HDVR index descriptor contains the following information:- 

a file offset {HdvrtndexAddress[1... MaxHdvrtndexNumberf) (in numbers of blocks) in the content part, 
35 hdvr_file_content_data, of the HDVR file which defines the HDVR index position. The STS is divided into blocks, 

and the STS portion pointed to by the file offset corresponds to a time-date (measured from the beginning of the 
STS) that is proportional to the HDVR index position into the HDVR index descriptor array. The n^ index maps to 
a point which corresponds to n x Hdvr_time_stamp seconds having passed since the start of the STS; 
an array of CMM family indices (HdvrIndexCMM[ 1... MaxHdvrtndexNumber] [1 ... ComponentNumber}) that define 
40 which CMM descriptors (CMM_ld) are required to decipher the portion of the STS pointed to by the particular 

HDVR index. For each of the Component Number components (video, audio, teletext) a reference to the CMMJd 
of the corresponding CMM_tabie is given for each index, facilitating trick modes during subsequent reading; 
the chapter identifier to which the HDVR index belongs; and 

the private PMT identifier (HdvrlndexPMTVersion[1... MaxHdvrtndexNumber) that is used to demultiplex correctly 
45 the STS portion pointed to by the HDVR index. 

[0385] The USER index part of the index table, of maximum size MaxUsertndexNumber, is a one-dimensional array 
of USER index descriptors. Note that USER indices are not sorted by time. Each USER Index {U serf ndex[1 ...MaxU- 
sertndexNumber) is, as a matter of fact, a reference to a particular HDVR index, which corresponds to a particular STS 
50 play entry point. Each USER index contains the following information :- 

a status that defines whether the USER index is either enabled or disabled; and 

the HDVR index reference (Hdvrtndex_ld) corresponding to the time-date that a user wanted to bookmark (taking 
the origin as the beginning of the STS). Note that this information is relevant when the relevant status is enabled. 

55 

Creation of Index tables 

[0386] The index table is constructed in two stages:- 
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Creation of an Hdvr Index table by hdvr_ mor a„ 

[03871 The Hdvr Mate l.ble I. cMM.d and oodaed „p„„ ^ „ , h „ ate 

■ - -ssssr sssssr-* 1 8 M ** a — ■ — — » 

Creation of the User Index table by the hdvr_player 

the User ,o Application to HDVR le one 117 P ° int ' ,n takin 9 int ° account 

it from an entry in the Htolnte^tabZ^^^^Z^ " " 9 ?' indeX " y de ° iding t0 calculate 
is sufficiently small (1s or 1.5s). Hdvr rounds thi tSSl o? w PaC Tl° f '"^ P °' ntS (W ^ rfn ^ 77 '" eS ^ 

multiple of HdvrtndexTlmesJnp and hen fll. fhe iS^L ^ " d,n 9 ° f tne '^ertion of the Index to the closes 
index point, Hdvrlndexjd. Usorlndex f.eld ,nd,cat,ng the identity of the corresponding Hdvr 

Use of index tables 

S rJale » ttS^^^E^^ r6adin9 ° f * « we,, as infer- 

[0390] Two methods exist: 

- use of the index table alone 

■ 22 2 issEssr - sections inserted durin9 recordina - ie: .00^^^ 

Use of index tables alone 

in^S *» **"»"■■ This mode o, operation 

tageous to test its performance in nomSS^SS^S^ ^ " reW ' ndln9 - additi ° n ' " ™» be adva - 

Stic :zs isxxss siizr 15 rr in ien9th ' * 900 — 

performed by the HDVR:- P X 1 ff ° m the 5 m,nute - The Allowing functions are then 

- search for the 300th index, Hdvrlndex in hfmd 
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- read the address stored at that index, HdvrlndexAddress[300] t and updates the current position, cur _pos 

- read the CMM corresponding to that index point, HdvrlndexCMM[300][1...ComponentNumber], and update the 
current CMM, cur_CMM[1... ComponentNumber] 

- optionally, construct or update the table in anticipation of loading the subtable HdvrlndexCmm[300-n...300+n][1... 
ComponentNumber] 

[0393] HDVRJJSER then sends the Identifier of the current CMM, curjCMMft, to the CM PS, recovers the control 
word and descrambles the components. 

[0394] There follows a request to read forward in the file, HdvrlndexAddress[301]-HdvrtndexAddress[300] blocks 
which correspond to a reading of 1 second. 

[0395] At the time of receipt of Evt_Write_Fifo_Comp!eted t the preceding commands are repeated for the 301 st 
Hdvrlndex. 

[0396] The advantage of this solution resides in the synchronisation of the descrambling processes, and of navigation 

in the index table; there are no asynchronous modifications of the CWs. 

[0397] The principal pitfall is the double anticipation of the CMM positions by this operation: 

a first overestimation, upon recording, of maximum duration cryptoperiod/security_coeffident seconds in the per- 
manent regime, and of cryptopehod seconds in the critical transitory regime, 
a second overestimation, upon reading, of a maximum duration of HdvrtndexTimeStamp s. 

[0398] Knowing that a CMM applies to 2 cryptoperiods, this last approximation of approximately one second should 
not perturb the descrambling of the data in reading mode of speed x 1 . All the more since in Trick-Mode, this solution 
becomes unworkable. 

Use jointly of Index tables and sections inserted upon recording 

[0399] Upon the recording of a file, for each cryptoperiod and for each component, there is inserted a section that 
can be filtered by the Mload device upon reading, allowing one to obtain information concerning the change in CWs 
in the STS, as well as that contained in the hfmd. 

[0400] Unfortunately, because of the approximation of the CMM positions in CMM_table upon recording, there is a 
variable discrepancy between the CMM information of the STS stream, Evt_CAS_Ecm(1... ComponentNumber), and 
the information contained in the hfmd, HdvrlndexCMM[1...HdvrlndexNumber][1... ComponentNumber]. To understand 
this discrepancy, consider the n th transition from CW(n-) to CW(n), as illustrated in Figure 23. 
[0401] Performing a reading using the inserted section to change the cur_CMM. 
[0402] From the index i: 

- update cur_CMM> ie HdvrlndexCMM[i]=CMMJd(n) 
read up to index i+1 

no section between i and i+1 
comparison between cur_CMM and Hdvr/ndexCMM[fh 1] 

same value 
read up to index i+2 

1/ change of CW at the level of the STS 

2/ the Mload on the section inserted beforehand generates an Evt_Top_Ecm 
3/ incrementation of cur_CMM, which becomes CMM_ld(n+1) 

comparison between cur_CMM=CMM_ld(n+1) and HdvrlndexCmm[i+2]=CMMJd(n) 

Attention, the value in hfmd is retarded by one index. 

read up to index i+3 



29 



EP 1 286 349 A1 

no section between i+2 and i+3 

• comparison between cur_CMM=CMMJd(m.1) and HdvrlndexCMM[i+3]=CMM_ld(n+ 1) 

same value 
- the retardai of the index is made good 

ESS S if me AnSt Pr ° dUCeS 3 retardal ° f indiCeS ' bUt thiS pTOblem can be compensated for. 

L2S. S^I.'SiSSSZSr a readin9 ,rom index i+2 ' the resutt of the combined - <* 

- update cur_CMM, ie HdvrindexCMM[i+2]=CMMJd(n) 

- read up to index i+3 

no section between i+2 and i+3 

- Comparison between cur_CMMJd(n) and HdvrlndexCMM[i+3]=CMM_!d(m- 1) 

si 5 ; s^^rsr an index in advance - one has theref ° re m — - 

- one has confidence in cur_CMM. and one keeps a retarded Ecm (dangerous) 

- one has confidence in HdvrindexCMMp+3], and in this case what is the use of the inserted section 

- information of position in hfmd (in Hdvrfndex or CMM_Table) 

- sections inserted in the STS 

- the process of estimation of the Ecm positions is valid (hybrid filter, as discussed in more detail belouri 

" ^"*ZT imeStamP fS SUffidem " Sma " ^ Pr6CiSi0n " the CW t-si JnsT'Cto^Ecm re- 
[<M09] More detaiied discussion of the synchronisation of CMMs, and estimation of bitstream positions is provided 
Structure of HDVR files 

Other tables included In the management portion of HDVR files 

StcLd^mo^SS' 68 Whi ° h m8ke UP ^-'"^^ent.maO. and which were listed above, are now 
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CMM table 

[0414] CMM Information provided by the CMPS Is stored by the HDVR Server In a dedicated two dimensional table. 
Each element of the CMM table is stored according to two coordinates:- 

5 

firstly, the CMM table identifier, which refers to the particular CMM family the CMM descriptor belongs to ; and 
secondly, the CMM identifier, which refers to the particular CMM Index of the CMM descriptor In the particular CMM 
family. 

10 [0415] Each element of the CMM table is classed as a CMM descriptor and contains the following information : 

- a file offset in blocks of the CMM position related to HDVR file content data that allows the HDVR to decipher the 
STS from this CMM file offset to the next one 

the first HDVR Index to reference this particular CMM (this is a cross reference between the HDVR index table 
15 and the CMM's) 

CMM structure as defined by the CMPS 

Chapter table 

20 [0416] The chapter notion is similar to that of DVDs. In particular embodiments, a recording always contains at least 
one chapter. Chapters are also play entry points and the chapters are linked to the HDVR indices. The chapter beginning 
markers, as well as their characteristics (see below) are transported by the CMMs provided by the CMPS at the time 
of the recording phase. A recording comprises a maximum number of MaxChapterNumber chapters. 
[0417] The chapters are stored together in a single table referred to as Chapter_Table() which contains a maximum 

25 number of chapters, MaxChapterNumber. 

[0418] Chapter information arises from two distinct sources:- 

firstly, from the HDVR chapter table; 

secondly, chapter information is provided during recording from a broadcaster and encapsulated into a special 
30 CMM that holds what the HDVR defines as the CMM chapter control. In further variants this CMM chapter control 

holds viewing rights in a similar fashion to existing MPPV. 

[0419] In order to group into the same structure all information related to a chapter descriptor, a reference to the 
special CMM is inserted into each chapter descriptor as the CMM chapter control's coordinates. 
35 [0420] The chapter table is a one-dimensional array of HDVR chapter descriptors. Each chapter descriptor contains 
the following information :- 

the HDVR index reference {Hdvrlndex_tcf) corresponding to the time-date that isbookmarked by the chapter (taking 

the origin as the beginning of the STS); 
40 - the chapter duration; 

a trickmode bitmap that specifies for each trickmode, such as pause, fast-forward, fast-rewind and so on, whether 

the particular trickmode is enabled or disabled. This trickmode is suitable for the whole chapter; 

a control viewing word that is compared with the parental control data structure according to a particular HDVR 

algorithm and defines whether the chapter is viewable or not ; for example, according to a user's PIN code and 
4 5 the moral content of the current chapter. 

special CMM coordinates (the so-called CMM chapter control, as discussed above) 

Private PMT table 

so [0421] The Private PMT (programme map table) is a PMT belonging to the HDVR which takes an inventory of the 
information necessary for the exploitation of the components of the recorded or soon-to-be recorded service. It com- 
prises two pseudo tables, one of which is provided by the client (who knows about the nature of the components), and 
the other of which is provided by the CMPS (which knows the active conditional access (CA) PID for each component). 
[0422] During the recording, the recorded service plan can be modified; there can therefore be one or more private 

55 PMTs applicable to the recording. One MPEG section inserted into the STS marks each development of the recorded 
service plan. Furthermore, the HDVR inserts up to three other MPEG sections in the recorded bitstream. 
[0423] The number of applicable private PMTs is limited to MaxPrivatePMTN umber. 

[0424] They are grouped together in a table referred to as Private_Pmt_Table() which takes inventory of a maximum 
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ESS P !5S 6aCh take an inVSnt0ry 0f ^^nents MaxComponentNumber. 

^Thd^SZ^X "n^'mensional array of private PMT descriptors. The HDVR private PMT descriptor 

thI u «^bodlment of a common MPEG-2 defined PMT (see ISO/IEC 13818 for further information). 
[0426] The following .nformation is added / removed to an ISO like PMT to create an HDVR private PMT- 

- HDVR use's PI D information, indeed the HDVR inserts some of its own PID into the original TS to obtain an STS 

- PID information relating to unrecorded components is removed from the original TS to obtain an STS For each 
component, CA PID information (CA standing for Conditional Access in this context) is removed as the CA aspect 
is managed by the CMPS and the HDVR does not deal directly with the CA content 

- for each component some CMM information is added to allow the HDVR to playback encrypted STS. So the CMM 
family which the component depends upon is specified. 

- for HDVR internal use, the CMM family to which the CMM chapter control belongs is specified 

- a file offset in blocks of the private PMT descriptor position related to the HDVR file content data for which the 
present private PMT descriptor is suitable 

- the HDVR index reference corresponding to the time-date whose origin is the beginning of STS, from which the 
present private PMT descriptor is suitable 

Rights and the Parental Control Data Table 

[0427] The rights group together the information relating to the authorisations associated with the playinq of a pro- 
gramme and are ali supplied once the programme is recorded. 

[0428] This information is stored together in a single table referred to as Parental_Control_Data() 

The Parental Control Data structure provides viewing rights control with a chapter granularity. It is used by the HDVR 

server to allow or forbid access to a chapter section or the whole file according to two different processes:- 

- a comparison between a parental control data PIN code and the user's own PIN code level with an external control 
such as a PVR control (where PVR stands for Personal Video Recorder, the high level end-user API of video 
recording functionality). The access control is suitable for the whole HDVR track file. 

- a comparison between a particular parental control table that associates a parental chapter control word for each 
chapter of the HDVR chapter table. In particular embodiments, it enables or disables the viewing control mecha- 
nism. If viewing control is enable for a particular chapter, then the HDVR server compares the global parental 
viewing control word with the related chapter viewing control word and fixes the HDVR automaton player state 
according to an interna) HDVR algorithm, such as forcing the automaton to a pause mode before the chapter 
concerned begins. K 

[0429] In certain embodiments the HDVR provides free read/write access to the parental control data and in such 
embodiments, the HDVR cannot be responsible for the efficiency of the parental control mechanism. 

Maximum values table 

[0430] In order to make the management data structure dynamic, the maximum sizes of each of the tables are 
provided in the header of the HDVR file. This table is referred to as Max_Values(). 

L°^f/ 1 J r ° le ° f Maxlmum Values is t0 assume the dynamic structure of HDVR file management data. So for each 
HDVR structure declared above, except the general information basic structure, the Maximum Values structure spec- 
ifies its offset and length into the HDVR file management data. This provides an easy mechanism to extend the internal 
format without any compatibility problems. So, for example, an old HDVR server is able to read newer HDVR file tracks 
in the case of HDVR file tracks exported between two different STBs via a firewire bus. 

Generalities and the General Information table 

[0432] The generalities group together the general information on the recorded programme. They are stored in a 
table referred to as Gen eralJnformation(). 

[0433] General information contains the followings at a sight information:- 

- a CMPS private information so called CMPS file identifier. Note that this information is CMPS read only mode and 
do not pass through the HDVR server API. 

- the HDVR Server version number which creates the current HDVR file track 
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- the delta time elapsed from one HDVR index to the next one. It can be also viewed as the HDVR index time 
sampling period. 

- the HDVR file track's total duration 
the total STS size in blocks 

5 - the current allowed time-shifting depth. Note that a null value is considered as an infinite time-shifting depth, for 
example in the common case of file recording. 

- the definition of a client private zone given by its HDVR file management data offset and its length. Note that HDVR 
Server API does not provide any read/write access to this dedicated zone. Client zone input/output operation is 
on client's charge. 

10 - the recording mode from the different following allowed states:- 
immediate mode for an user instant recording 

push mode for a broadcaster's special use, for example to upload commercial offers 
programmed mode for a one-shot differentiated recording 
15 - periodic programmed mode for a periodic differentiated recording 

time shifting mode. 

the HDVR Player Server identifier if there is currently an HDVR Server playing the HDVR file track, in order to 
avoid concurrent file access 

20 - the HDVR Recorder Server identifier if there is currently an HDVR Server recording the HDVR file track, in order 
to avoid concurrent file access. 

Storage of HDVR management data 

25 [0434] For the hdvr_file. management_data, the CMM Table (CmmTab) is a large table (several Megabytes) and 
filling it depends on the broadcast characteristics and the duration of the recorded programme. In order to avoid the 
CmmTab occupying space unnecessarily on the disk, the table Is not created on the disk with the maximum value 
(CmmMaxNumber), but gradually during the recording. On the other hand, the offsets for achieving the different Cm- 
mTabs (in the case of internal encryption) take into account the CmmMaxNumber value. 

30 [0435] With reference to Figure 24, one therefore obtains on the disk an hdvr_file. management_data made up of 
holes. 

[0436] Figure 24 illustrates a special functionality of the GFS library that allows a file to have a virtual size superior 
to its effective disk allocation size. For example, HDVR File management data has a virtual size that can provide 
complete management for a total HDVR track duration of 20 hours. However, generally, the HDVR track is only 2 or 3 
35 hours long. According to the GFS library holed-file feature, the virtual size of HDVR file management data is not entirely 
allocated: some unallocated clusters are present into the hdvr_file.management_data offset range. 

HDVR content data - Stored Transport Stream 

40 [0437] Leaving discussion of the management data stored by the HDVR and returning to discussion of the structure 
of the stored content, the STS (stored transport stream) is now described in more detail. 

[0438] The STS is the name given to the bitstream recorded by the HDVR and is made up of the following data:- 

reproducible data of the service to be recorded (clients choice) 
45 . one or more sets of video data 
one or more sets of audio data 
one or more sets of subtitles 
teletext information 
data inserted by the HDVR 

50 

[0439] The data inserted by the HDVR is in the form of MPEG sections and is referred to as 
HDVR_<section_name>_SECTION elsewhere. 

[0440] The HDVR_NEW_PMT_SECTION is inserted in order to mark each recorded service plan change. 
[0441] There is a maximum of MaxPrivatePmtN umber- 1 HDVR_NEW_PMT_SECTION sections in the STS. 
55 [0442] The HDVR_TIME_TAG_SECTION section is periodically inserted in order to provide an indication of the time 
that has passed during the playing of the STS. This section is optional. 

[0443] The HDVR_CAS_ECM_SECTION section is only used in the case of internal encryption of the reproducible 
data (DVB-CS) and is inserted to mark the beginnings of the cryptoperiods. 
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[0445] There are as many different types of HDVRCAS_ECM_SECTION sections which distinct ECM Pin. fnrth. 
recording servce. An HDVR CA9 ppm ccrnnM ~ ^ 7 ns wn,cn aisnnct tCM PlDs for the 

y ice. «n nuvH_CAS_ECM_SECTION section type is therefore associated with each CMM famiiy. 

Recordal of data 

[0447] Figure 25 illustrates the flow of data between the HDVR controller and the mass storaoe dav™ Tho 
o7Seren" s r ^ ^ »"* * * a F ' F ° ^^S^S^Sj: 

KZL»il!^ re,ln9 ^ 0m ! r,S ! 8 3 maximurn of MaxCmmNumberCMM. The returned CMM contains an encrypted part 

Sth?;xrrs 

Internal encryption 

[0450] For internal encryption, the reproducible data, upon leaving the demultiplexer 230 remains encrvoted and 
IT" * T°" m T n T° n thS d6C,yption °' the -Preble data is then doS Tat Z^KSJ, Te 
riodTh!^ ^ dCaSt USi " 9 the ECM trans P° rted on one orseveral ECM PIDs and are vSUone cZope 

nod. The changing of the cryptoperiod is signalled within the broadcast. The decrypting keys are reSveredT^h 
new cryptopenod by the HDVR server by using the services of the CMPS server * 

EmT» » ' n ^ emal encryption - there are as man y CMMs as there are cryptoperiods for the duration of the recordinn 
within the MaxCmmNumber limit: the encryption is said to be temporal srorine duration of the recording 

ErinnH?! 1 ri nn MR f tranSP0rtS ' amon 9 other thin 9 s - a P air of keys (referred to as CW: control words) which allow the 
decryp ,ng during playing, for one cryptoperiod. of one or several reproducible components. The CWs are found Z he 

17oZVcZ ^ " Ct *«* «P'««-* oy the HDVR: it is Necessary to « cZl for an 

[0453] For this type of encryption, there can be ECMs as a service which can be applied to one or several or even 
all of the reproducible components. Consequently, the CMMs are grouped together by CMM family and Z Z 

map table (PMT). To each of these fam.Hes, there are associated dependent encrypted components, for example: 

ECM PID X broadcasts key pairs for the reproducible video component 
ECM PID X broadcasts the key pairs for the reproducible audio component 
ECM PID Y broadcasts the key pairs for the reproducible teletext component 
ECM PID 2 broadcasts the key pairs for the reproducible subtitle component. 

External encryption 

[0455] For external encryption, the reproducible data, upon leaving the demultiplexer 230 is in the clear and tha 
encryp ion of this data is done at the time of writing on the disc and the decryption fs done at the «me of Sayinq Tne 

sssszxz applied are detem,ined by ,he cmps and recovered b * ,he hdvr — Cixiz^i 

m 45 ^ 1 m ' 6 T r ? a] encr yP tion ' there can be as many CMMs as there are keys applicable to the recordino within tha 
i^TbeT" 

EX J a °H °m M transDOrts the ke y <"^inafter referred to as CK) which allows the encryption and decryption of 
1 hLT , ,b e K c 1 om P° nents ° f the recording service. The CK is found in the encrypted zone of me Sand is 
not d.rectly exploitable by the HDVR: it would be necessary to ask the CMPS for an exploitable key 
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[0458] For this type of encryption, there is always only one CMM family. 

[0459] A CMM family is grouped together in a table called Cmm_Table() which contains a maximum of MaxCm- 
mNumberCMMs. 

[0460] The bit stream recording and playback procedure will now be described in more detail. The recording proce- 
5 dure involves the estimation of positions in the bit stream with which control words will be synchronised for the later 
playback process. The estimation is required in order to allow this recording technique to afford the advantages of 
security and minimal processing and storage. 

[0461] Turning to a second general aspect of preferred embodiments, the estimation of position in a bitstream, and 
the synchronisation of conditional access information with the bitstream are now described in more detail. 

10 

CMM SYNCHRONISATION 
Bit stream synchronisation 

15 [0462] Before discussing some problems associated with recording scrambled bit streams and their solutions, the 
structure of such bit streams will now be described with reference to Figure 26. 

[0463] In Figure 26 a scrambled MPEG bit stream 1300 (such as that received at the receiver/decoder from a broad- 
cast centre) is illustrated. The bit stream as shown is divided into successive cryptoperiods 8000, 8002, 8004, each 
scrambled with a corresponding control word. The bit stream 1300 also contains Encrypted Entitlement Control Mes- 

20 sages (ECMs) 8010, 8012, 8014. 

[0464] To provide the system with some redundancy (and therefore fault-tolerance), each ECM in fact contains two 
control words: one for the present cryptoperiod, and one for the following cryptoperiod. Thus ECM 8010 contains the 
control words to descramble both cryptoperiod CP7 8000 and CPS 8002. Similarly, ECM 8012 contains the controls 
words necessary to descramble both cryptoperiod CP8 8002 and CP9 8004. In fact, the ECMs are periodically retrans- 

25 mitted to ensure the continued smooth operation of the system in the event of the user changing channel ('zapping') 
or a temporary fault preventing reception of the first set of ECMs. For simplicity, only the first ECM in each such series 
is shown. 

[0465] The conditional access smartcard 5500 typically takes several seconds to decrypt each ECM, but each cryp- 
toperiod is relatively long (1 0 seconds in the preferred embodiment), so there is not generally a problem with timing in 

30 the case of receiving and decoding live content (such as that received via satellite from a broadcast centre). 

[0466] In the case of recording an audio/visual bit stream (such as a received digital television broadcast) to hard 
disk and the subsequent playback, timing can be more of a problem, since, in general, conditional access data relating 
to a recording will have to be manipulated before, during or after storage in order to overcome the time-limitation of 
the recording (in other words, remove the dependence on the time-varying global encryption key Kq used to encrypt 

35 the incoming ECMs). 

[0467] It has been found advantageous to synchronise the scrambled content 800 (in the form of an audio/visual bit 
stream) with the relevant ECMs, so that the control words 5600 can be fed into the descrambler at the correct time to 
allow the content 800 to be descrambled. More precisely, it has been found useful to synchronise the audio/visual bit 
stream and conditional access data (preferably, as noted above, in the form of the original ECMs) at the time of storing 
40 the audio/visual bit stream and conditional access data. 

[0468] The synchronisation process is performed by the HDVR 3850 in preferred embodiments. Alternatively, the 
synchronisation process is performed by the CMPS system 2300. 

[0469] During the synchronisation process, a reference is made between the conditional access data and a corre- 
sponding position in the bit stream. Typically, this reference takes the form of two pieces of data: the identifier of a 

45 CMM corresponding to the conditional access data (ECM) and the corresponding file write pointer (FWP) in the bit 
stream. In the preferred embodiment, such a reference is stored in a table in the previously-mentioned management 
data portion 2112 of the file also containing the stored bit stream, so that it can be easily accessed during playback. 
[0470] The synchronisation can be brought about by evaluating the position of each ECM as it arrives, storing such 
positions, and reloading the stored positions during playback as the basis for timing when the control words should be 

so delivered to the descrambler. The evaluation of such positions exactly to the nearest bit or byte in the bit stream can 
occasionally be inefficient. 

[0471] Some issues concerning the exact determination of the position of an ECM in a stored bit stream will now be 
considered in the context of the present system, where the bit stream is fed from a demultiplexer into a remultiptexer, 
then into storage in a hard disk via a FIFO. 
ss [0472] Data, such as ECMs, is extracted from the output of the demultiplexer by the MLOAD device, operating semi- 
autonomously of the upper software layers in which the control ofthe synchronisation process is more easily managed. 
Due to interrupt latency and other similar considerations, the receipt of the ECM from the MLOAD device cannot be 
precisely timed. Furthermore, receipt of the ECM is usually only acknowledged by a EVT_CAS_ECM event 8400 (not 
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whX^oTnoTlS lcMl C .°n'l d J i0nal a °? SS SmartCard aftGr Ce,tain Checks have been mada (including a check as to 
a t.m« „ff«? , ° r mere ' y 3 re,ransmlssl °n)- This event will lag the actual receipt of the ECM itself by 

a time offset, herein referred to as At, and the amount of data corresponding to At will varv deoendlno on th» „r!„! !i™ 
bit rate of the bit stream. The subject of At will be returned to later * dependlng on ,he P^vailing 

TJ?\ h if 8 " 6 10 ° 0nSider iS th3t the FIF ° buffer has a d y" am i«»»y adjustable size, and may vary between emotv 
a " d ™^ 

FWP) is only determinable before and after the writing of each segment (of perhaps, 2 Megabytes of data at a time) 

n!™"^ FWP Cann0t be read 81 any arbitra, V ,ime < when ' ,or an EVT.CAS ECM arLes) } ' 

[0474] The net result is that an exact determination of the ECM position can require additional analysis of the bit 

SE SSSKSST '*•"* kn ° wttd9 * - - Ma " °""*" s """" -— >— -~ S2 

Estimation of positions in the bit stream 

[0475] As explained briefly above, each ECM relates to a particular 1 0 second cryptoperiod and also contains the 
control word for the next cryptoperiod, which offers some scope for a different solution for evahSyJ^Sn^ 
the ECM, namely estimation (rather than determination) of the position position or 

!°f^l im V ' ar i i0US t means h .*» *»n found of estimating the position, and some of these will be described later One of 
the more efficient means involves manipulating the bit stream in such a way that the worst-case estimate relaUveS 

methods By safe it ,s implied that, during the reconstruction of the stored bit stream using the above estimated 

^In^H « ! m ' n9 : th u e ° 0ntr01 W ° rdS Wi " eaCh be delivered ,0 the ^rambler during the appropriate 
cryptopenod ime-window, and the descrambling operation will thus operate correctly. If, by contrast, a control wor7is 
delved during the wrong cryptoperiod, the descrambler will fail to descramb.e the stored bit stream, resZZ in a 
loss of picture and/or sound for the user. leaumng in a 

[0477] This above-mentioned means for estimating the position of the conditional access data (or any other aooro- 

hS « 'lt?r S T 9 ? tS 821 ' S22 ' 823 and 50 ° n are Sh0W " in relation 10 the bit strea ™ («Wch is shown 

TJ»L , 0ffSet ) SCa,e " due t0 va, V in 9 bit ra «^. as discussed later, the segment sizes would be distorted and 
uneven if a time scale were used). Also shown is the equivalent file write pointer (FWP) values, and the prevailing 

t P"!fu 00 Wh ' Ch ° CCUrS at a time At ,ater The bound aries of the segment are shown as dashed lines 

" ° f *° EC t M f 02 and EVT_CAS_ECM event 8400. Lastly, the correspond^ estimated posftfonTfth ECM 
(FWPest) is shown to the nght of the end of the segment containing the ECM 5602 

222, JUl 6 K nd °' 3 Part ! CUlar S69ment (and ther6f0re the be 9 innin 9 of the ne * ^gment) is signalled to the CMPS 
2J?^J?^SJS r9ey res P° nsible ,or the estimation) near-lnstantaneously by the reception of an 
Z ;T-T^ D 6Vent ' 9Cnerated by the maSS St0raae device to ^ate'that the current segment 

t s :zt:^t^t pomt - the current Fwp can be assumed to be equai to ,he previous ™ 

[0480] The estimation comprises determining the segment in which the ECT_CAS_ECM event 8400 falls (since the 

EE T- °H 6 f h CM "I 02 " itSe " 9 '° bal,y n ° ti,ied - n0t ,eaSt because ™ st received ECMs a ' a "lere re ransmis 
sions which are then subsequently discarded by the conditional access system), and then taking the estimate of the 
position according to the following formula: m»™ub or me 



FWPest = E^" =l size_segment(0+ size_fifo} + k 

' Sn^nt^n^" ° Perat 1 r ' siz ^ e9ment(n) is ,he si2e of each se 9 me "» the present illustration, 
s ze_segment(22) = 2 Mb for example, and the sum of all previous segment sizes is 30 Mb), sizejito is the amount, 
of data in the FIFO (which, as noted, can vary), and fcis a "security parameter" (typically between 0 and 1 Mb) 
which adjusts for further latencies and timing problems in the system so as to ensure the estimate is an overestimate 

(S6G DGlOW). 

[0481] The expectation term E() in the above eguation addresses the fact that the sizejito parameter at least cannot 
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be determined exactly. Typically, for a given maximum allocated FIFO size fs (say), E(size_fifo) is taken as Yi fs (which, 
In the above example implies a maximum FIFO size of 0.2 Mb). As will be described in more detail later, the choice of 
size_segment can be fine-tuned to keep the resulting estimate 'safe' yet efficient. 

[0482] In the example given in Figure 27, E(fifo_size) is taken as 0.5 Mb, k is equal to 0, and the lsize_segment(i) 
5 term is equal to 32 Mb, yielding a FWPest of 32.5 Mb when the above formula is applied. 

[0483] Underlying the above formula is the realisation that, because of the double control word redundancy of ECMs, 
It does not matter if the estimated position of the ECM falls within the cryptoperiod immediately after that with which it 
is associated. The estimation will fail, however, if the estimated position falls within cryptoperiods beyond that, or in 
the cryptoperiod immediately preceding the correct cryptoperiod. 
w [0484] In Figure 27, for example, during the writing of segment S22, it is impossible to distinguish between 
EVT_CAS_ECM events 8400 caused by ECMs sent in respect of cryptoperiod CP1 2 and EVT_CAS_ECM events 8400 
caused by ECMs sent in respect of cryptoperiod CP13. Since to incorrectly label a CP12 ECM as a CP13 ECM is not 
critical, and incorrectly labelling a CP13 ECM as a CP12 ECM is fatal, the need for an overestimate can therefore be 
appreciated. 

15 [0485] It should also be considered that the maximum segment size can not exceed the size as a cryptoperiod (less 
the size of the FIFO size parameter), since with larger segment sizes there exists the possibility of receiving two 
EVT_CAS_ECM events 8400 within the same segment write operation, and two sets of control words. This too is fatal, 
since, owing to various system constraints described above (and others, including the asynchronous nature of inter- 
device communication), there is ambiguity about the order in which the corresponding ECMs were received, which can 

20 lead to the wrong control words being applied to the wrong cryptoperiods. 

[0486] Bearing the above in mind, the robustness of the estimation routine in extreme cases will now be illustrated 
further with respect to Figures 28 and 29. 

[0487] In Figure 28, an incoming ECM 5602, resulting EVT_CAS_ECM 8400 and estimated position of the ECM 
(FWPest) are shown. This represents one extreme case where the EvT_CAS_ECM event 8400 is received just before 
25 the EVT_FIFO_WRITE_COMPLETED event, at the end of the segment S22. The resulting estimate (32.5 Mb, in fact) 
here is at its closest to the ECM 5602 (at a distance of 0.5 Mb plus the data size equivalent to At), and in this case falls 
within the correct cryptoperiod (CP13). 

[0488] In Figure 29, the ECM 5602 and resulting EvT_CAS_ECM 8400 are shown fractionally further forward in the 
bit stream, with the EvT_CAS_ECM 8400 occurring within the next segment S23. The resulting estimate (34.5 Mb, in 
30 fact) here is at its furthest from the ECM 5602 (at a distance of 2.5 Mb plus the data size equivalent to At), and falls 
within the cryptoperiod (CP14) after the correct cryptoperiod (CP13). 

[0489] Other examples can be constructed with different relative positions of cryptoperiods and segments, but it can 
be observed that with the above formula (and with a combined segment and FIFO size no greater than the size of a 
cryptoperiod), the estimated position always falls within the correct cryptoperiod, or the following cryptoperiod (in both 
35 cases, with acceptable results). 

Structure underlying the synchronisation and estimation 

[0490] The various structures underlying the methods of synchronising and estimation described earlier (particularly 

40 with reference to Figures 12 and 13) will be described in more detail, with reference to Figures 30 and 31 . 

[0491 ] In Figure 30, the scrambled bit stream BOO is shown passing through the demultiplexer/remultiplexer/descram- 
bler 2010 (here shown in its remultiplexing capacity) and FIFO 8020 (operated by the FIFO device 3744 - not shown) 
on its way to being stored in the file portion 2110 in the hard disk 2100 (operated by the mass storage device 3728). 
The MLOAD device 3438 extracts ECMs 5602, and URMs 5612 and CMPS_EMMs 5614, and forwards these to the 

4 5 conditional access system 5000 and CM PS 2300 respectively. Control words 5600 decrypted by the conditional access 
decryption engine 8500 in the conditional access system 5000 are sent to the CMPS 2300, accompanied by the broad- 
cast of an EVT_CAS_ECM event 8400. As described earlier, the control words (two per CMM for redundancy), URMs 
5612 and CMPS_EMMs 5614 are combined and encrypted by the CMPS decryption engine 8550, and then sent, via 
the HDVR 3850, and the mass storage device 3728, to the hard disk 2100 for storage in the management data portion 

so 2112 of the relevant file. EVT_FJFO_WRITE_COMPLETED events 8410 are broadcast periodically (and received by 
the HDVR 3850 in preferred embodiments, or alternatively by the CMPS 2300 directly) when a segment write operation 
has completed. EVT_CA_CMM events 8552 are sent from the CMPS 2300 to the HDVR 3850. 
[0492] In Figure 31 , the demultiplexer/remultiplexer/descrambler 201 0 produces the desired unscrambled bit stream 
810 by descrambling the scrambled bit stream 800 from the portion 2110 with control words 5600 generated by the 

55 CMPS decryption engine 8560 in the CMPS 2300. The above-mentioned decryption engine 8560 is fed by CMMs 
retrieved from the management data portion 211 2 of the relevant file in the hard disk 21 00 via the mass storage device 
3728, and also produces URMs 5612 and CMPS_EMM 5614 for further processing by the CMPS 2300. 
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Segment size 



Kei^ 

■safe' (in other words, small) J^SSSZ 7eS£ Tl ixo^H 1 ,urther co " si ^ration is that particularly 
more EvT_FIFO_WR|TE COMPLIED evem^ Sch if^f? 8 °' cr yP to P eriods *<* inefficient, since the 
necessarily used up. " " " re 9 eneratea P er second, the more processing power is un- 

[0494] The optimal segment size is now considered in more detail: 

degradation of computationa! efficiency; 9 P6r C ^P^ which can lead to a 

p^eulng lo a minimum while kt««„o .« . ™ !e = m *" t » "» ■» '"W »■ P0»lbl. to k.ep 

EinlTof IS^ST^ LTmlimf' 3 T" * ^ >— * the 

size) whilst retaining^ esSs of S [position efflC ' enCV ^ 0t *" r m3Ximise the 

sr^ i"*, « the su r ptibiii,y of ,ne estima,ion p^- ^ •S^se? r,ng in most 

Optimising segment size 

= and dynamics 

[0501 ] First of all, static filters will be described 

StS^ 

determine optimum segment SZS to cZT^ll i^ZZZT^J ? 2 f ^ ' S * 
rate. However, static filters have a tendency t^rZ,I? ' Y 631 l6SS We " wrth lar 9 e variations in bit 

the bit stream to c^enem^ «** - of 

Constraints affecting the choice of this constant segment size include the following: 

[0503] The size of the segment must no, exceed a cryptoperiod in iength (also taking into account buffered data) 

Slze_Segment (Mb) < bit rate (Mb/s) x cryptoperiod (s) - FIFOSize (Mb) 
[0504] The maximum size of transfer (segment size) is limited 

Slze_Segment (Mb) < 32 (Mb) 
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10 



50 



[0505] The following assumptions regarding the above parameters are not unreasonable: 

One cryptoperiod is at least 6s 

The bit rate is at least 1 Mb per second 

FIFOSize is less than or equal to 32 Mb (and typically 2 Mb) 

[0506] These above assumptions give the result that: 

Size_Segment (Mb) < 6 (Mb) - FIFOSize (Mb) 



(and consequently that FIFOSize « 6). 

[0507] With the typical FIFOSize of 2 Mb, the segment size is therefore 4 Mb. 
[0508] Dynamic filters will now be described. 

15 [0509] A dynamic filter adjusts the size of the segment to accommodate the bit rate. High bit rates have short duration 
segments and vice versa. The dynamic filter must, however, compromise between few large segments and many small 
segments. If the bit rate is low or constant, the segments can be large, creating fewer events per cryptoperiod while 
still affording the resolution necessary for the recording and synchronisation of the bit stream. If the bit rate is high or 
varies greatly, the smallest segments are required to afford the most accurate measurement, but create many events 

20 per cryptoperiod, thus degrading the bit stream manipulation. The aim of the dynamic filter is to create the largest 
segments possible for the bit stream. 

[0510] The dynamic filter attempts to limit the segment size to the equivalent of a time expressed as a fraction of the 
cryptoperiod (referred to below as the 'segment writing time'). The factor defining the segment writing time is an integer 
called the 'security coefficient 1 , such that: 

25 

segment_writing_time = cryptoperiod — 

sec unty_coefficient 

[0511] There are 3 different types of dynamic filter discussed below; rapid, inertial and hybrid filters. In the preferred 
30 embodiment, a hybrid dynamic filter is used, but in variants of the preferred embodiment other types of static and 
dynamic filter are used. 

[0512] The rapid dynamic filter takes into account the writing time of the preceding segment in order to determine 
the size of the subsequent segment. First the rapid filter calculates the time taken to write the previous segment 
{time_segment(n-1)-time_segment(n-2)) t and then calculates the corresponding average bit rate (equal to the size of 
35 the segment divided by the time taken). The size of the segment (n), size_segment(n) is then given by the formula: 

size seament = size^segment(n^) x cryptoperiod 

- y time_segment(n-'\)-time_segment(n-2) security_coefficient 

40 [0513] Time_segment(n) is the absolute time of the reception of the event of that segment (n) (rather than the duration 
of the segment). 

[0514] In equilibrium (that is, with a constant bit rate), the filter gives security_coefficfent number of writes per cryp- 
toperiod, regardless of the actual bit rate. In the case of a low bit rate, the limit value of the size of the segment is the 
same as that of the static filter case, that is, size_segment = 4 Mb. 
45 [0515] As an example of the use of a rapid dynamic filter with a constant bit rate, using the above formula, if the 
value of the cryptoperiod is fixed at 10 seconds and a security coefficient of 4 is chosen, a segment event takes place 
every 2.5 seconds. In the case of a constant bit rate, the system converges towards the limit as defined above. 
[0516] The principal constraint on the dynamic filter is as follows: 



time_segment(n) - time_segment(n-1) < 1 cryptoperiod 



[0517] It can be deduced that at the segment border, the average bit stream (averaged over one cryptoperiod/ 
security_coefficient) does not exceed the security coefficient relationship given earlier. The stability of the filter is guar- 
55 anteed in this case if: 



averagejbitjrate (t + cryptoperiod) > average_bit_rate (t) x security_coefficient 
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!efiS m GXamP,e * ^ SGen th9t ^ dynamiC " ,ink6d t0 th * SeCUrl * coefficje * * the following 



Dyn 



t n+ cryptoperiod 

1— bitrate d * ( 20* ^(security _coefficient \ 
\ cryptoperiod ) 



cryptoperiod 



dB/s 



so thatTJc^ COnditi -- ™ * * — n control values for the filters 

[0520] The second type of dynamic filter is an inertial multilevel filter. 

[0521] The principle of this filter is the same as that of the rapid dynamic filter in that it ^timatoc th* hi* rot < 

SSiS? b « str rT usin9 the bit rates of previous segme " te; ^sj^^ts^tk; 

memory (that m, effectively it has more filter coefficients). Here, the average bit rate is taken as m^Kera^ 

Z, EThE ? S" Pr f° US Secwri *- co <™ "-»*« of segment write operations The es, maflon oMhte 
After has a higher mert.a than the first level filter, which allows it to be more stable, though it may be less sensitive to 
the peaks of the b.t streams. The inertial filter is simiiar to the rapid filter in that it uses the wrZ time vales She 
segment^securrty coefficient) to the segmental ) in order to obtain the size of the segment(n) 
[0522] The formula of the filter is as follows (geometric form): 



size _ segment = 



cryptopenodi 



[t-cryptotnnod~( ' ' " — r - 

=J 17 stze_segment(n-i) \ cryptoperiod 

\ ,., \ time _ segment (n - i- 1)- time_segment[n- i)J * security coefficient 



(in arithmetic form): 



size_ segment = 

j size__segment(n-i) \ cryptoper iod 

cryptoperiod ,., Ume_ segment^ - i - 1) - time _segment(n - i)j * sec urity_ coefficient 

Sm ', im > ValU6S '° r 8 ° 0nStant bit ra,e in ,hS dynamic ,il,er are identical to th ose of the static filter and those 
w,th dynamic mrts are equivalent in terms of performance to those of a rapid fitter, the oniy difference being the re 
sponse t,me of the .nertial fitter (at the securi^coefficient level) which has a memon, of one c^toTeriod 2er than 
a memory of a cryptoperiod/secur/fx.coeff/c/enr as for the rapid filter crypiopenoo rather than 

^Sc^^^^T^TJT^ al T S thC redUCti ° n °' V6ry hi9h peaks < and thus *• Possibility of 
it!t>r*M, k ^ peakS)l that ,s ' peaks of a hlaher d y namic tha " the security coefficient allows The 

oSSva^^ 

[0525J The third type of dynamic filter is a hybrid hysteresis filter 

S„ ZTrZ° n, nam xK fi,terS deSCnbed ab0VS (rapid and inertial multi,evel oVnamic filters) are combined to give a 
better performing filter. The resultant hybrid filter combines the best characteristics of the two filters The rapid Ntter 

seoment 9 °r t 0d r o POnS V ime "1™^ C3Se °' & ^ M dr ° p ' but wh en it identifies a located S n a 
segment, rt can overestimate the size of the subsequent segment because of the large value being included* the 

B^VZSXEZ inertial ,i,ter can dampen brt ra,e peaks ' Jfts response Le= r * 

ESnHi™! hy r rid f " ter accomm odates for the hysteresis effect (that is, the difference in its reaction to rising and 
descend.ng fronts ,n the bit rate) by combining the rapid and inertial filters and keeping the flexibility of an inertiaUHter 
on a „s,ng btt stream front in order to dampen any localised peaks; and the reactivi J ofthe rapid filter on a desSndlTq 
bttstreamfrontmordertocompensateforthe transitions of the high bit rate bit streams towards low btt rTtebisSams 
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[0528] The behaviour of the filters has been investigated using simulations of typical bit streams, which wilt now be 
described. 

Bit rate simulations 

5 

[0529] Different bit rate patterns are investigated in Figures 32 to 39 using the four filters described above: static, 
rapid dynamic, inertial dynamic and hybrid dynamic filters. 

[0530] The objective of the simulation is to observe the behaviour of the filters out of their stable behaviour zone 
(that is, not at a constant bit rate). To achieve this, different input bit rate functions are investigated, Including a sinu- 
10 soidally varying bit rate (Figures 32 showing the results of the static filter; Figures 33 for the rapid filter; Figures 34 for 
the inertial filter; and Figures 35 for the hybrid filter), a step function bit rate (Figures 36 for the hybrid filter only), a 
triangular function bit rate (Figures 37 for the hybrid filter only), a top hat function bit rate (Figures 38 for the hybrid 
filter only), and a single peak bit rate (Figures 39 for the hybrid filter only). 

[0531] In each set of figures, the figure denoted "a" shows the bit stream over time and the figure denoted "b" shows 

15 the resulting writing time over the number of segments. 

[0532] The figures denoted "a" in each set of Figures 32 to 39 have vertical lines showing the transition between 
segments. As can be seen from Figure 32a (the static filter case), for example, a constant segment size takes a short 
time at high bit rates - reflected in the bunching together of segment transitions at approximately 3, 16, 28 and 41 
seconds - and a relatively longer time at lower bit rates - reflected by the large (temporal) segment widths at approxi- 

20 mately 9, 22, 35 and 47 seconds. As described above, the aim is to avoid such bunching of segments (which results 
in an unnecessary degree of accuracy at the expense of computational efficiency) - in other words, aiming for larger 
segment sizes at high bit rates. 

[0533] The figures denoted M b" in each set of figures each indicate the 'crash line' B600, which is equivalent to the 
cryptoperiod duration (in this case, 6 seconds). As noted previously, a writing time in excess of this duration can cause 
25 the estimation to fail (because more than one ECM may arrive during the writing of the segment). For the dynamic 
filters (Figures 33 to 39), there is a second horizontal line which shows the writing time to which the dynamic filter 
converges. 

[0534] As mentioned previously, Figures 32 to 35 relate to a sinusoidally varying bit rate simulation lasting 50 seconds; 

in this case, each cryptoperiod lasts 6 seconds, and a security coefficient of 4 is chosen. 
30 [0535] The static filter, rapid filter and dynamic filter create 100, 33 and 28 segments respectively (the fewer the 

segments, the better the filter, in general). The segment writing times are all observed to be below the crash line (that 

is, less than the cryptoperiod in length), and there is no observed instability in the behaviour of the filter. 

[0536] In this test, the hybrid filter offers the best correction of the three dynamic filters and so the other bit rate 

simulation results focus only on this filter. The tendency towards instability is corrected by the hysteresis phenomenon 
35 between the increase and decrease, which is illustrated by the damping 8700 on the increasing front and increased 

reactivity 8750 on the decreasing front as shown in Figure 35b. 

[0537] As mentioned previously, Figures 36 relate to a step function bit rate simulation lasting 50 seconds; in this 
case, each cryptoperiod lasts 6 seconds; and a security coefficient of 4 is chosen. The bit rate of the bit stream is 1 
Mb/s for 25 seconds and then 8 Mb/s for the subsequent 25 seconds, creating a step between two different constant 
40 bit rates. The object of this simulation is to investigate the behaviour of the filter around the typical minimum bit rate. 
[0538] The dynamic filters (rapid, inertial and hybrid) have the same characteristics at minimal flow as the static filter. 
However, they converge towards the limit of cryptoperiod fsecurity_coefficient. A maximum bit rate limit of 8 Mb/s is 
determined. 

[0539] As mentioned previously, Figures 37 relate to a triangular bit rate simulation lasting 50 seconds; in this case, 
45 each cryptoperiod lasts 6 seconds; and a security coefficient of 4 is chosen. The objective of this simulation is to observe 
the behaviour of each of the filters when faced with a bit rate which increases then decreases. 
[0540] The hybrid filter combines the elevated response time of the inertial filter on the rising portion 8850 of the 
triangular bit rate function, with the strong reactivity of the rapid filter during the decreasing portion 8900 of the triangular 
bit rate function. 

50 [0541] As mentioned previously, Figures 38 relate to a top hat function bit rate simulation lasting 50 seconds; in this 
case, each cryptoperiod lasts 6 seconds; and a security coefficient of 4 is chosen. The bit rate consists of a 'top haf 
at 8 Mb/s on a base of 2 Mb/sThe maximum limit allows the hybrid filter to be at an established bit rate on the bit rate 
plateau at 8 Mb/s. 

[0542] As mentioned previously, Figures 39 relate to a single peak bit rate simulation lasting 50 seconds which also 
55 incorporates an element of noise; in this case, as before, each cryptoperiod lasts 6 seconds; and a security coefficient 
of 4 is chosen. The bit rate has a weak average noise value around 2 Mb/s, and it presents a very localised bit rate 
peak for 2 seconds with a height of 18 Mb/s. The objective is to show the hybrid filter's capacity for damping a strong 
bit rate peak which is greater than its correction capacity, in order to compensate for anomalous bit rate measurements 
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when estimating the bit rate 
[0543] - 
for 



Further methods of estimation 

of the bit stream (as opposed to forming the e£E2 ft onS fZ ttT? dependence on a characteristic 
as described above), such as the average bl rate or £J TJZL S . 8 Part ' CU ' ar Segment > ,or exam P |e - 

[0545] One such method will now be described P etWee " P °' n,S ,he b,t stream - 

[0547] The position of the ECM .MhfbTs^ - E ™ — - -.ed). 

2. An average bit rate during this time period is estimated- 

offset ("Ad") found above ^ " then Ca ' CUlated as the present Portion (FWP) less the data 

word is approximate* constant (of the orde o a couple o^nl^ "* T ^ taten t0 d6C,ypt a control 
previous estimate can be measured and used ,o corral "t >- T^' h ° W9Ver ' the error in at least one 
for estimating At. ° COfreCt fu,ure est, ™tes. Other means may of course be provided 

Ad(Mb)= Bit rate (Mb/ s) x At (s) 
d = FWP- Ad 

to take into account different informal ^X^^K^^SP * laa * 

however, noted that dedicated integrated Scu ts capaSe of oerfoZ^K ^ W '" n0t be d6SCribed in detail - 11 is - 
are commercially available or can be reaZT s ^°°JZ™»l °TT* the ^iver/decoder 

or more preferably modified to produce a ? r* 8 ^^"^ 8 ^. 

required, thereby reducing the pL^poS^^^^^T' l ° ,mplemef1t va *°us of the operations 
implemented in software if sufficient iSSJjS £ Ziab.e ^ H °" W " "* ° Perati ° nS ™* 

actua, indentation of these features and the 



42 



EP 1 286 349 A1 

modules could be Implemented In software, preferably written In the C programming language and preferably compiled 
to run on the processor used to run the application; however, some components may be run on a separate processor, 
and some or atl components may be implemented by dedicated hardware. 

[0559] The above modules and components are merely illustrative, and the invention may be implemented in a 
variety of ways, and, in particular, some components may be combined with others which perform similar functions, or 
some may be omitted in simplified implementations. Hardware and software implementations of each of the functions 
may be freely mixed, both between components and within a single component. 

[0560] It will be readily understood that the functions performed by the hardware, the computer software, and such 
like are performed on or using electrical and like signals. Software implementations may be stored in ROM or may be 
patched in FLASH. 

[0561] Turning to a third general aspect of preferred embodiments, command sets for controlling the transfer of a 
bitstream are now described in more detail. 

COMMAND SET 

Command set 

[0562] The Personal Video Recorder application (henceforth referred to as the 'PVR') 31 54 mentioned above is part 
of a Personal Video Recorder system ('PVR system') which allows the user to record audio and/or visual data (principally 
programmes broadcast to the receiver/decoder) to a mass storage device, such as the hard disk 2100, and also to 
play back such audio/visual data. The data is stored as sequentially-ordered data (in MPEG-2 format in the preferred 
embodiment) and in essence the PVR provides the user with different ways to access this or similar data (indeed, a 
corresponding application for recording and playing back purely audio content is also provided, using fundamentally 
the same principles as will now be described). 

[0563] With reference to Figure 40, the PVR system will now be described in more detail. The hard disk 2100 (or 
other mass storage device) is connected via FIFOs and memory buses (not shown) to both the demultiplexer/descram- 
bler/remultiplexer 2010 and MPEG decoder 2028, such that audio/visual data can be routed freely between the live 
broadcast signal input (outputted by the tuners and demodulators, not shown), receiver/decoder memory (not shown), 
MPEG 2 decoder (for display on the connected television, not shown) and hard disk 2100. 

[0564] The hardware components mentioned are controlled by software devices (not shown), and in particular by 
the mass storage device 3728 and (indirectly) the service device 3736. In turn, the mass storage device and service 
device are controlled by the hard disk video recorder (HDVR) module 3850, comprising two recording threads 3854, 
3856, a playback thread 3858, and shared filing system library ('FS library') 3852. Finally, the PVR application 3154 
issues commands to the HDVR module via the program interface 7000. 

[0565] As can be seen in Figure 40, the PVR system is broken down into several layers, with the effect that the PVR 
application, essentially residing at the top of the chain of command, can entirely ignore lower-level considerations such 
as allocating space on the hard disk for recording and managing file pointers, and so on. By the careful design of the 
interfaces within the PVR system, as will be described in more detail below, the instructions which the PVR application 
3154 sends to the underlying HDVR module 3850 correspond closely to the sort of axiomatic operations which are 
performed by the PVR, such as commencing playback at a given position in a stored programme, and stepping through 
the programme frame-by-frame. 

[0566] Whilst the interface 7000 between the PVR 31 54 and the HDVR module 3850 can allow simpler applications 
to be developed, providing as it does several different commands each corresponding to a typical user operation, the 
interface 7002 between the recording and playback threads 3854, 3856, 3858 by contrast implements a minimal com- 
mand set, in particular providing only two commands for reproduction of data (one to set the reproduction speed, and 
one to set the reproduction position) which can allow the efficiency of the underlying FS library to be increased. The 
further interfaces between the FS library and devices, and between the devices and hardware, allow further levels of 
abstraction. 

[0567] Four principal levels of command that are provided will be described later, including a first top-most layer 
7010 of commands (comprising the PVR routines), a second midrange layer 7012 of commands (comprising the rou- 
tines in the recording and playback threads 3854, 3856, 3858), a third layer 7014 of commands (comprising the FS 
library routines), and a fourth bottom-most layer of commands, comprising automata 7016. As mentioned above, of 
course, further layers of commands exist below and possibly above these four layers, but these are as earlier described. 
[0568] Underlying the playback aspects of the PVR system are the concepts of 'current reproduction position' and 
'current reproduction speed' (referred to elsewhere simply as 'current position' and 'current speed' respectively). These 
two values are interpreted by the hardware (hard disk, demultiplexers, remultiplexers, MPEG-2 decoder and/or FIFO 
systems) to control the playback of programmes and/or other data stored on the hard disk 2100, and can be altered 
by various parts of the controlling software, as will be described in more detail later. In terms of the recording aspect 
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S tt ^ 3856 their -SvoteS a ' PnnC ' P,eS deS ° ribed h6re Can ab ° ba appHed 

seek_s.ngle_play() 7010, seek_slow play() 70^2 seek nn^T 1^ HDVR pla y back rou «nes-) are shown a 
7018 and pause() 7020 routine. In tumVe FS^^T* S£S 2 * Seak - fast -P'ay<) '016 singte p" ay( ) 
0 FS hbrary routines'): a set_pos() 7030 and a se sold f™£ Command 701 4) provides two commands (the 
command layer 7010), its const lent S^SSS^Z^' ^ P ™ aPP " Ca,i0n 3154 is al *° shown ( ^ 

Sdt— od^ n ^r toas - 

stream, bu, in variants of the preferred «**ES'52S ZteveZTlTT* ^ ° f ,ha st ° red 

m many types of encoded video or audio stream , Zd in MPtr , , 9 reco 9 nise that » byte-offset from an origin 
to the time offset from that origin. Therefore Z^eTlZTe^TT^ "* h9Ve 3 COnstant ,inaa ' "ete .on 
he offset and the spatial offset. This can be a hiS t a oivenT. ' " | nS ' ati ° n reqUired interna My b «ween 
t-me offsets to byte-offsets, and refined by subs^^^SZ Z^ by USing ,ab,es whic " map 

ind the desired frame. ,n a further variant, the pS! he se, I'n 9 " Sh ° rt ' ength ° f the MPEG 2 d *a to 
Honed table of byte-offsets. parameter of the set_pos() command is an index into the above-men- 

[0S75J For performance reasons, whenever tho^t 

then scans forward to find and disp.ay 1£Z?S£^JZ^£^ " ^ l ° the Specified P-Won and 
m formats other than MPEG) after that position Se ZaZT™^ ' 88 ° PP ° Sed t0 - frame 

can in sllgw JerWnewWnaomeapJlloaa^W^iJ^T.^ 115 ' 0Ccurever V half second, this behaviour 
the set_pos() command causes the MP^ decoder ^T^^^^^^^^nt-how^r 
toward again to the desired position (which t^ a *£S£^™ ' T** PreV '° US and » a 

atter behaviour can result in generally smoother playback Te dS '"t^olated frame). Whilst slower, this 
[0576] The set_speed() routine sets ; the <i„J I, Z , l ™f J 6 decoder ,s sufficiently advanced), 
eter. Again bearing in mini the Z'ZTr Kjo^SZtT^ '° ^ ^ « as a pa — 
of norma, playback speed (that is, a parameter ofTaSa^ 

less than 1 is equiva.en, to slow-p.ay. Passing a p a rami er of 0 has ° ' aS, ; forwardin 9. and a parameter* 

parameter ,s equiva.en, to rewinding the stream In ^Il oJS! , ^ ° f PaUSi " g reproduc «°n. and a negative 
.n different units, such as the number of frames p^rsecoSrexamn XT embodiment ' ,he Parameter is specified 
between frames (the inverse of the number of frames per sectndTJr ' for , norTna l Playback), orthetime inseconds 
sources with a constant ra(e Qr jn sjtua ^me r secon ^"^P'f • «° f " norma, playback). For video 

££? speeds of fast forwarding cr rewinding, for 2™^^^ ° h° 9 ^ PUrP ° Se P ° SSib,e t0 idnore 
[0577J The nature of some encoding methods used ToTaulvk,! I J? V S ° Sp6Cified in terms ° f bitrate. 
example) is such that it cannot be read Cher than S stamna Zn « I °' d3,a < SUCh as MP ^ *r 

signal ,n one direction, whereby a time point into^^l?"*" P °' h " f ° Ward throu 9" the 

cannot be decoded backwards. This is in parttoular herZ , advances as decoding proceeds. In other words it 
the form of a collection of transport Pe^^X^JlS^T^ * MPEG 2 f °™ f 

.n a time-reversed manner, multiple short read operations ™1« transfer speed. In order to reproduce the data 
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ESLJ^xrir m " d ' imp,emen,s an au,omaton which vaiidates nav,ga,ion - 
E ft.^n , sis!r:s by ,he ,ourth layer 701 6 in pre,erred embodiments va,wates the iinkina - — 
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State of the Automaton 



[0580] The letters a and b used in the table represent speeds of either playing, slow forwarding or rewinding or fast 
forwarding or rewinding. a 
[0581] The symbols in the lefthand column represent the state of the automaton upon receipt of a command the 
symbols in the top row represent commands sent to the automaton, and the entries in the table represent the corre- 
sponding states of the automaton after execution of the commands. 

[0582] So for instance, if the initial automaton state is fast forwarding at speed a, and a jump chapter forward com- 
mand is received, the system will jump forward one chapter and then play out at normal speed, rather than continuing 
to fast forward through the new chapter. a 
[0583] The fourth command layer receives set_position and set_speed commands from the third command layer 
and. given the current state of the system, validates that the commands would produce a transition to an allowed state 
mil!.? °T! W ° Pr ° dUCe 3 ,ransition t0 an al,owed stata «^n the commands are passed for execution 
.. U V commands received b V the fou t" command layer would produce a transition to a state which is not 
Z automaton ' then in tne sim P |est ca *e the fourth command layer would cause the command to be ignored 
[0585] However, in preferred embodiments, and for certain commands, and states of the system, if the commands 
received by the fourth command layer would produce a transition to a state which is not allowed by the automaton 
then rather than causing the command to be ignored, the fourth command layer alters either the set_position or 
set_speed command and then checks whether this new command would produce a transition to a valid state If so 
the new command is passed for execution, and if not the command is again altered. This recursive attempt to validate 
t 8 ra C Stton"to , a ItrikUtato amendment °' the command Proceeds until a command is produced which would cause a 
fowardinrop'eration 3 " 06 embodiments il is not allow ed to jump to a new position in a file during a fast 

[0587] Initially, during a fast forwarding operation the state of the system may be expressed by the following table 
which records the state of the current set_position, X. and set.speed. V. commands, and flags whether these states 
have changed (flag value=1 ) or remain the same (flag value=0). 
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[0588] Upon receipt of a command to jump to a new position, 



the table changes:- 



X 


1 


0 


V 


1 


0 



ditional access parameters aisa,,owed b V the automaton ,n dependence, in part, upon parental control or con- 

chapters in a flle containing 

such content. M ^naming aauit content, if the user does not have permission to view 

S mSSS SSSSK ° f a " emb0dlment ' n WhfCh f ° Urth C ™ d ^ is link ed to a parenta, 

ssj^^stj: z:zztz •js*r* , r a * the state °< the ~ -u-*-. *. 

value=0):- 98 Wh6ther ,hese states have Ranged (flag value=1 ) or remain the same (flag 



X 


1 


0 


V 


1 


0 



[0595] A set_pos command is then received: 



35 



40 



X 


2 


1 


V 


1 


0 



kjsszej^:^^ :sr t: ,h> us - — - — — — - 

ta.snted by these commands i. allowed" "Uwoon to bo amended, and obseta Mn, ,h. transition tap. 



X 


3 


1 


V 


1 


0 



whether the transition represented by th JoTiSS to i»owt^„1h b f amended ^ a " d again checks 
reset to zero, the commands are passed for e^cution and Z lit ^ tM ™ '* a,,OWed ' the fla 9 s are 

which was originally requested- e «cut,on and the system plays content from a later chapter than that 



X 


4 


0 


V 


1 


0 



Fot tba M. o, a,,^ a « voM ooni™; ^SS^S^T" ™' 0> W " n °™ b ' <tec * ed 
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PVR symbols 



10 



15 



25 



30 



C v; m Y\ r\ 1 

i^y muui 


r unction 




Plow 
i lay 


♦ ♦ 


Fab l lUrwaTQ 




poet rpxi/in/l 


> 


OlOW IOrWaiQ 


< 


Slow rewind 




Next Index 




Previous index 


C+ 


Next Chapter 


c- 


Previous chapter 


QD 


Pause (freeze frame on an image) 


a 


Stop 
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[0599] Typically, each of the above PVR application functions is invoked by the user pressing a single button on the 
remote control, or selecting a single option in an on-screen menu. Thus, they correspond to axiomatic commands from 
the point of view of the user (distinct to axiomatic commands from the point of view of the software (such as the 
set_speed() and set_pos() commands described earlier). Further or alternative functions to those listed above can, of 
course, be envisaged; in particular, the above could be adapted for use as an audio player, for example, with indices 
corresponding to music tracks, say. 

[0600] Still referring to Figure 41 , the six commands provided by the HDVR playback thread 3858, in the second 
command layer 701 2, will now be described. 

[0601] As mentioned above, the six commands in the HDVR thread 3858 comprise four 'seek-play' operations- 
see k_single_play() 7010; seek_slow_play() 7012, seek_normal_play() 7014 and seek_fast_play() 7016. In addition to 
these basic operations, there are two other elementary operations: sfngle_play() 7018 and pause() 7020. These op- 
erations together encapsulate the functionality of the above-mentioned set_pos() 7030 and set_speed() 7032 routines 
in higher-level routines which are of more use to the PVR application 3154 and similar applications. These routines 
will now be described in more detail. 

[0602] Each of the seek-play operation sets the positions of a current read pointer, in the data stream and then 
continues to reproduce the stream forward of that pointer in one of several modes, in the process making use of both 
the set_pos 7030 and set_speed 7032 routines to achieve the desired effect. In the preferred embodiment, the param- 
eters of the six routines are equivalent to the parameters of the underlying set_pos() and set_speed() routines (that 
is, centisecond time offsets and multiples of normal play speed respectively). However, in variants of the preferred 
embodiment, different parameters (such as, for example, byte-offsets and inter-frame delay, respectively) may be spec- 
ified for the six routines 7010, 7012, 7014, 7016, 7018, 7020, with the necessary translation of parameters taking place 
within the routines before the set_pos() and/or set_speed() routines are called. 
[0603] The operation of each of these routines will now be described. 

• seek_single_play() sets the current reproduction offset to the offset specified as a parameter of the routine, and 
then reproduces a single frame from (or as near as possible to) that offset, whilst the playback remains paused 
It is used by PVR routines which alter the position in the stream (0,0 , C-, C+) when the playback has been 
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paused (0 ). 



speed. It is used during normal playback (asTct laTeS ^bv thTpvTn, ' pr ° t C6ed, "9 ,hrou 9 h *° stream at normal 
the position in the stream ( 0, 0 , C-, C+ ) V "* [ ® J) by PVR routines which alter 

' re"^ 
' norma- ™- du ^ 

' ^Z^^ spewed as a parameter of the routine, and 

-no™,™ 

• -^^^^ 

nisms outside the HDVR ^SE^\^i?S2^^SSi2^ ^ dhph * d6ViCeS; ™ cha 

are used to actually control the video output, ^7^^ 3734 ^ RF ° *"» 3744 

see k _slow_p,ay () and 

HDVR playback routines to be simplified, so that they S neetto «££ ST ! < * n advanta 9 e ° u *'y a «°w the 
or playing, fast-forwarding, rewinding, slow-playin an so onMn ° ° P . T, 0 " 6 m ° de ° f P ' ayback < such as P au ^ 
!££ ""ST* r ° U,ineS CapablS ° f ' * ^4 pSmode nantS ° f Preferred emb ° diment ' 

of Jp£ ^ In' ^rffSX^^STff^ - "» PVR ^ ' f " d « 

Derived Functions 

current reproduction posKion ^JeTZTZ^Tj^T " ^ fUnCti ° nS - ^ *° 
UL^eTr^^ 

Play is emulated by jumping backwa ds through The data s^aT at .Lh memi ° ned ab ° Ve ' ^o-reversed 

fn^nT l ° ° btain 8 Sin9,e ,rame ' and **PW?9™*s!^ZZ JUmP deCOdin9 S Sh ° rt Se9mert of ,he data 

represented by a horizontal line, and each verticaiTow %ZZZ T** 4 * * 4?1 Wh,Ch tne data strea ™ «■ 

speed reproduction in the forward direction ♦♦ 
^^JauIe O^ 6 ^ 10 " ^ Gmb0died in the f0,,0win g sequence: 
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seek_fast_play (cur _pos) 

[061 2] Figure 42 Illustrates the operation of the seek Jast_p lay () routine on M PEG data (comprising periodic l-frames 
as shown). As can be seen, the audio/visual data is scanned forward at a high rate (limited by the decoding hardware 
to a i maximum of between 8 to 12 times normal playback speed, for example), and images are periodically displayed 
at the refresh rate. The displayed frames are a mixture of l-frames and non-l-frames, depending on where the MPEG 
decoder had reached at the time for the screen refresh. 

[0613] As noted above, one of the more compact embodiments of the seek_slngle_play() and related functions takes 
a parameter of the actual data offset in the audio/visual file, instead of the time offset. 

[0614] In the case where a very rapid advance is required, and in all additional cases where the MPEG-2 decoder 
is capable of doing so, a short routine can be constructed to effect a fast-forwarding function using the above-mentioned 
data-offset vers.on of the seek_single_play() routine. This short routine is shown below, with reference to Figure 43 



pause 0 

Loop during play_time 

cur_pos += constant_data_pffset 

seek_single_play (cur_pos) // display the frame at the cur_pos data offset 

in the audio/visual file 
pause during pause_time // wait for next refresh 
EndLoop 



[0615] This method uses a technique of spaced forward jumps in the stream. The value of playtime corresponds 
to the durat.on for which the command remains active. It is also possible to adjust the value pause time to modify 
the video rendition. 

[0616] The offset for each jump ('offset' in the code above) can be calculated as a multiple of the average bit rate of 
the audio/visual data, such that an offset of, for example, three times the average bit rate will result in a reproduction 
speed of approximately three times the normal play speed. As can be seen from Figure 43, however, the bit rate of 
the audio/visual data is typically not constant with respect to time (certainly for MPEG data), and so a constant data 
increment results in an uneven playback of frames. 

[0617] Nevertheless, using this latter method, the time taken to fast-forward is approximately constant regardless of 
the reproduction speed, so that the reproduction speed can be made arbitrarily high (such as 1 28 times normal playback 
speed) and otherwise easily varied during the fast-forwarding operation. It can also be observed that less time is spent 
scanning through the data in this example, as not all the data needs to be scanned. 

[0618] A more advanced fast-forwarding operation can be achieved using the following code, similar to the last but 
using the time offset* version of the seek_single_play() routine (whereby the current reproduction position is specified 
as a time offset into the audiovisual data). 



pause() 

Loop during play_jime 

cur_pos += constant__time_offset 
seek_single _play (curj>os) 
pause during pause_time 

EndLoop 
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Knu^ Present examp-e, the co„ S tanUime_o«se, (and 

multiple of the period between l-f ames fcl be slen Z ST . ? ^ ViCe V6fBa) are chosen t0 be a 

displayed are equally spaced In els 0 time rZZl ?„ T i^T t0 de °° de iS m0re Unifo ™' and the 1"*™* 
(described previous*) to the set poT< m Se tc aHow ft o ISJET ^r^'" 9 aCti ° n - With the modification 
been described so that non-l-frame can be decld^ 7fl w P L * ° ther than '- frames which has Previously 
can effectively be used. frameS ° an °* decoded, a fast-forward speed of other than a multiple of the .-frame period 

appZa^Sro^ a time offset (,ime_offse„ and the 

fields is as follows: ' 9 ndeX teble ( lndex -* a °te'> containing both time offset and data offset 

index = 0 

while (index Jable[index].time_offset < time_offset) 
{ index ++ } 

data_offset = index_table[index].data_ofiset 

pauseQ 

curjndex = GetCurIndex(cur_pos) // find current index using methods 

detailed above 

Loop during playjjme 

cur_pos = index Jable[curJndex].data_offset 
seek_single_play (cur_pos) 

cur>dex+=n // higher values of n give faster effective 

reproduction speeds 

pause during pause__time 
EndLoop 

High speed reproduction in the reverse direction ♦♦; 

K jausyjsas: ess (no ' ' i ™ > * >• — *~ - - — — <* 
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pause() 

Loop during play_time 

cur__pos - = constant_data_offset 

seek_single_play (cur_pos) // version of the seekjsingle _j>lay routine 

using data offsets as parameters 

pause during pause _time 
EndLoop 



[0623] As before, the speed of the reproduced video can be controlled by adjusting the duration of the delay (by 
varying the parameter pause_time), and varying the displacement within the stream, by adjusting the parameter 
constant_data_offset. 

[0624] Again, it can be seen that the distance between frames is erratic, and the progress backwards uneven In this 

and the following example, care has to be taken that the jump backwards is sufficiently large to span at least one I- 

frame (otherwise, a loop could be entered which displayed the same l-frame endlessly). 

[0625] A more sophisticated version is shown in Figure 46, using time rather than data offsets: 

This may be done as follows, and is illustrated in Figure 45: 



pause() 

Loop during play time 

curjpos - = constant_time_offset 

seek_single_play (cur _pos) // version of the seek_single_play() routine 

using time offsets 

pause during pause_time 
EndLoop 

[0626] As before, it may be appropriate to allow variation of the reproduction speed within, for example 1 to 128 
times normal playing speed. 

Slow speed reproduction in the forward direction > 

[0627] As illustrated in Figure 47, this feature can be embodied by the following code: 
pause() 

seek_slow_play(cur_pos) 

[0628] As shown in Figure 47, the effect of the seek_slow_play() command is to scan through the audio/visual data 
at a slower-than-normal rate and display all of the frames as per usual (except displaying certain or all of them for more 
than one screen refresh period, depending on the playback speed). 

[0629] An alternative embodiment of the slow-forward command, using the single_play() command is as follows 
with reference to Figure 48: ' 
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pause 

Loop during play time 

single_play () 

pause during pause_time 
EndLoop 



2^ * ' * e «"fl • J>lay() routine (as opposed to the seek_single_play() routine) advances the audio/ 
visual data st earn by one frame (including non-l-frames). The routine differs from the seek slow play() variant given 
above in that the speed of reproduction (or more generally, the transfer speed, as described elsewhere) can easHy be 
customised by altenng the pause_time variable. y 
[0631] A further routine for achieving slow-forward capability, but using the seek_single_play() command is as fol- 



pause 

Loop during play_time 



cur_pos += constant_time_offset 
seek_single_play (cur_pos) 
pause during pause_time 
EndLoop 

[0632] This code is the same as one of the routines used to fast-forward, except that the pause time and 
constant_t.me_offset are chosen so as to effect fast-forwarding at a speed less than the normal playback speed This 

I2S ' S th°? USefU ' W r en thG seek - sjn 9 ,e -P ,a y(> rouftio is adapted to jump to non-l-frames as well as l-frames 
(reducing the time granularity from, for example, half a second to the normal refresh rate, such as 1/30 seconds) 

Slow speed reproduction in the reverse direction < 

[0633] To effect a slow speed reproduction, the procedure is as for the rewind function (♦♦), but with values of 
pause__t,me and currenUime.offset chosen such that the (negative) reproduction speed is less than the magnitude 
of the normal playback speed. A typical code fragment is as follows: 



pause() 

Loop during play_time 

cur_pos - = currentJime_pfFset 
seek_singlejplay (cur _pos) 
pause during pause _time 

EndLoop 
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Z?S A9ain ' ,h ° ° urrent - time - offset an <* pause.time parameters may be varied, and better results will be achieved 
with the version or the seek_single_p.ay() routine capable of jumping to non-l-frames as well as l-fmmes 

Complex Functions 

[0635] The three layers 7010, 7012, 7014 of commands (and more particularly the lower layers 7012 7014) can be 
used to construct further commands that perform functions of arbitrary complexity. The following ex^^Stra^ 
the power of the command layers (the "basic commands') described above. examp.es illustrate 

Example 1: Sequence of actions - 13 , C+, [H] , GO * >, ® 

[0636] Expressed in terms of basic functions, this function can be implemented by the following sequence: 

seek_normal_play (cur__pos) 

cur_pos = chapterjable [next_chapter].time_offset 

seek_normal_play (cur_pos) 

pauseQ 

single_play (cur_pos) 
seek_s!ow_play (cur_pos) 
seek_normaI_play (cur_pos) 

Example 2: Sequence of actions - 13 , @ , \u\ , 0 ( C- 

[0637] Expressed in terms of basic commands, this function can be implemented by the following sequence: 
seek_norrnal_play (curj>os) 

cur_pos = user_table [next_userJndex].time_offset 

seek_normal _play (cur_pos) 

pause() 

seek_normaI_pIay (cur_pos) 

cur_pos = chapterjable [previous_chapter].time_offset 
seek_normal_play (cur_pos) 

Example 3: Sequence of actions - B , C+, Q , ♦♦, > ( ffi] 

[0638] Expressed in terms of basic commands, this function can be implemented by the following sequence: 
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seekjiormal_play (cur _pos) 

cur jos = chapterjable fnext_chapter].time__offset 

seekjiormaljlay (cur_pos) 

pauseO 

Loop during playtime 

curjos - = current_time_offset 

seek_single_play (cur_pos) 

pause during pause_time 
EndLoop 

seek_slow_play (cur_pos) 
pause() 

[0639] As can be observed from the above, the three lavers 701 n 7mo 7ma * 

flexible yet simple interface to higher and lower software avers Z ^n l I I SGtS * aCh pr0Vide a 

provide higher levels of functionality Y ' " eaS " y be ,ncor P or ated into other routines to 

which recording is to take place, and the set soeed Sin Zft "V ° 8 ° command sets the Portion from 
can be set to oTher than norma ro^S^Sf to ™T L reC ° rd ' n9 ^ (WhiCh in SOme Pediments 
for example). Furthermore ZZSlSSitT 9 * frame - rates ° r S^^aily lower quality, 

tionality. ' dm9 a " d re P roductlon Processes can be combined to provide time-shifting func 

ESLn T ti0nS d6SCribed 3b0Ve ' and ** 

however, noted that dedicated integrate Ste oSSSS 'T te T ntor """ n0t deSCribed in de,ail - « 
are commercialiy available or <S^^SiZS InH ? h " 9 ° perations in ™e receiver/decoder 

or more preferabfy n^^^^SSS^r f 88 ^ baS ' S 3 hardWare aCCelerator ' 
required, thereby reducing the processing ^oo^r^T !T T^' t0 im P lement var '™s of the operations 
be implemented^ software if SSSS^SZ^St SZST^- ^ *" 

L^eTto^ 

actual implementation of these features and ft« nr^iff h ? , ? J nformatlon 9 lvenand specifications provided, 
modu.esL.dbeimp.emfnfed i^Zre pr ^era^writte^V/r ,0 *• imp,ementor - As an «ampre. certain 
to run on the processor used to ^^^£0^0^ P^W""* language and preferably compiled 

jjnj I some or a„ components rn^bTa^JS^^^ °" 3 « • 

Sofl^ a n d invention may be imp.emented in a 

some may be omitted in simplified S^S^^t^S^ T **** ^ ' UnCtionS ' 0r 

p^^c^^^^ by r hardware ' ,he compu - a - -oh 

patched in FLASH 9 " a ' S - SoftWare lm P |e ™ntations may be stored in ROM, or may be 

Anonyme, and whose content is intended as oart rtkl \ * ° f Cana,+ Techn °l°9ies Societe 

pendently or in any appropriate combination P apphcat.on) and the drawings may be provided inde- 
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Ks^Uhe e c n .rr aPPeari " 9 ^ bV W8y °' illUStrati ° n ^ and Shal1 have " 0 ■—0 « 



Claims 
1 



N^ e a r, mPriSin9 81 lea w St r6COrd mapP ' ng 8 res P ectlve da,a o^et in a file containing a representation of a 
bitstream to a corresponding time offset in the bitstream. 

2. A table according to Claim 1 , wherein the bitstream is a variable bitrate bitstream. 

3 ' per a o t d e = aCCOrdin9 t0 C ' aim1 ° f 2 ' Wherei " ,ab ' e com P rises at least threa re <=°rds. and the time offsets are 
4. A table according to Claim 3, wherein the period of the time offsets is varied. 

5 ' S25I! aCC °T g l ° 3 ° r 4 ' Wherei " ,he Per '° d ° f the ,ime 0ffse,s is chosen t0 mateh a characteristic of the 
bitstream, and is preferably 0.5, 1 , 2 or 10 seconds. 

6. A table according to any of Claims 1 to 5, wherein:- 

the bitstream comprises at least one portion of bitstream data which can independently be used to regenerate 
a respective at least one portion of audiovisual data; and sgeneraie 
the time offset of the at least one record corresponds to the respective at least one portion of bitstream data. 

7. A table according to Claim 6, wherein the at least one portion of bitstream data comprises a key frame. 

8. A table according to the Claim 7, wherein the bitstream comprises MPEG data, and the at least one portion of • 
bitstream data compnses an intra-frame. 

9. A table according to any of Claims 6 to 8, wherein the bitstream comprises at least one further portion of bitstream 
data which can be used to regenerate a portion of audiovisual data in conjunction with the at least one portion of 
bitstream data, and preferably the at least one further portion of bitstream data comprises a delta frame 

10. A table according to any of Claims 1 to 9, wherein the table is generated automatically during recordal of the 
representation of the bitstream in the file. 

11. A table according to any of Claims 1 to 10, wherein at least one record in the table is mapped to a respective at 
least one urther record, and preferably the said at least one further record comprisesconditional access information 
or content management information. 

12. A table according to the Claim 11 , wherein the said at least one further record is stored in a further table. 

13. A table according to Claim 12, wherein the said at least one further record is inserted upon command of a user. 

14. A table according to any of Claims 11 to 13, wherein the said at least one record in the table is mapped to the 
respective at least one further record upon command of a user. 

15. A table according to any of Claims 1 to 14, wherein the file is encoded and the at least one record maps a data 
offset in the encoded file to a corresponding time offset in the bitstream. 

16 " rhewStrelm" 3 '" 9 * ^ °' 1 * 15 ' Wherel " re °° rdS ^ '"'^ de P endence U P™ characteristics of 

17. A table according to any of Claims 1 to 16. wherein at least one record is inserted upon command of a user. 

18. A table according to any of Claims 1 to 1 7. wherein at least one record is inserted automatically. 
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19. A tab.e according to any of Cairns 1 to 18 adapted for storage in a fiie with the representation of the bitstream 

bitstream to a corresponding time offset inX bits^eam *" COntalmn9 " re P re8en **°" °' * 

21. A method according to Claim 20, wherein the bitstream Is a variable bitrate bitstream. 

22 iT^odr 0 ^ 9 10 C ' a,m 20 " 21 ' Where ' n the table « -st three records, and the time offsets 

24. A method according to any of Claims 20 to 23, wherein:- 

.he ,i™ effce, „, ,h. ., „. s , 0 „, c^p^ ,„ . „ speclive „ ^ one w ^ ^ am 

25. A method eecMng ,o CM* 24, wner.h, ». «, ,..„ on0 pMio „ „ 0teMm „,„ ^ _ ^ ^ 

^fepTe^r^ 

mation or content management inS^atioi ^ C ° mpriSeS COnditiona, access ^ 

30. A method according to the Claim 29, wherein the said at least one further record is stored in a further table. 

31 . A method according to Cairn 30, wherein the said at least one further record is inserted upon command of a user 

3 \^?h^^^ 

^ t^SSSSS. 01 C ' aimS 20 t0 91 ' eaSt ° nS rSCOrd iS inS6rt6d *P«-~ upon char- 

35. A method according to any Cairns 20 to 34, wherein at least one record is inserted upon the command of a user. 

36. A method according to any of Calms 20 to 35, wherein at least one record is inserted automatical*. 

" ^^Z n l^T^T 20 10 fUrth6r COmPriSin9 St0rin9 ^ t8ble * raining 

38 ^JS:^ 
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found. 

39. A method according to Claim 38, wherein the bitstream is a variable bitrate bitstream. 

40. A method according to Claim 38 or 39, wherein the desired portion of data is representative of bitstream data which 
can independently be used to regenerate a portion of audiovisual data 

41. A method according to any of Claims 38 to 40, wherein the step of jumping to a position in the file comprises 
reading a record from a table according to any of Claims 1 to 1 9 and jumping to the data offset given in the record. 

42. A method according to any of Claims 38 to 41 , wherein:- 

the step of jumping to a position in the file comprises reading a record from a table according to any of Claims 
1 1 to 1 9 and jumping to the data offset given in the record; and 
the at least one further record is used in the step of reading data. 

43. A method according to any of Claims 38 to 42, wherein the data offset in the record corresponds to the desired 
position in the file. 

44. A method of searching a file containing a representation of a bitstream for a plurality of desired portions of data 
compnsing searching for each desired portion of data using a method according to any of Claims 38 to 43. 

45. A method according to Ciaim 44, wherein the desired portions of data are representative of portions of bitstream 
data which are periodically spaced in time. 

46. A method according to Claim 44 or 45, wherein the desired portions of data are used to effect a fast forwardinq or 
rewinding operation. 

47. A method according to Claim 46, wherein the time period between the portions of bitstream data represented by 
the desired portions of data is chosen to effect a given fast-forwarding or rewinding speed. 

48. A method according to Claim 47, wherein the time period between the portions of bitstream data represented by 
the desired portions of data is chosen in dependence upon a characteristic of a means used to carry out the method. 

49. A method according to Claim 48, wherein the characteristic is the maximum sustainable rate of retrieval or process- 
ing of data from the file. 

50. A method according to Claim 48 or 49, wherein the characteristic is a read/write hard disk access time, or a parsing 
demultiplexer bandwidth, or an operating system scheduling accuracy. 

51 . A method according to any of Claims 46 to 50, wherein the given fast-forwarding or rewinding speed is varied upon 
command of a user. 

52. A file, comprising a representation of a bitstream, and a table as claimed in any of Claims 1 to 19. 

53. A processor for generation of a table according to any of Claims 1 to 19. 

54. A processor for analysis of characteristics of a bitstream and insertion of records in a table according to any of 
Claims 1 to 19 in dependence upon this analysis. 

55. A storage means for storage of a table according to any of Claims 1 to 19. 

56. A storage means according to Claim 55 for storage of the file containing a representation of a bitstream. 

57. A hard disk video recorder comprising a storage means according to Claim 55 or 56 and preferably further com- 
prising a processor according to Claim 53 or 54. 

58. A receiver/decoder comprising a hard disk video recorder according to Claim 57. 
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59. A receiver/decoder adapted to communicate w,th a hard disk video recorder according to Cairn 57. 

60. A broadcast system incorporating a receiver/decoder according to Ciaim 58 or 59. 

61 . Apparatus for evaiuating a position in a bit stream, comprising means for estimating the position. 

M ' SET.' CCOrdin9 ,0 C,aim 62 ' fUrth6r C ° mPriSing «" ^ the Known position from a piura.tty of 

64 2=ssskss STO.^swiisr pos,,,on is — <° — - 
66 = k nrs 

6 NX^™rence™ 

70. Apparatus according to any o, Cairns 61 to 69, further comprising means for storing the bit stream. 

71 ' XTom SSSir" ?0 ' fUrther C ° mPriSin9 m6anS f ° r ** — -ith the bit stream sepa- 

^ £*r n9 10 C ' aim 73 ' ,Urther C ° mPriSing mCanS - -ditiona. access data separateiy to 

76. Apparatus according to Cairn 75, further comprising means for storing the reference in a tabie 
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80. Apparatus according to any of Claims 75 to 79, further comprising means for estimating a position in the bit stream 
and wherein the referenced position Is selected in dependence on the estimated position. 

81 ' TSSS o a Sll a Z a °M? a,m H "I t0 72 I"* 80 ' '^^ °° mpriSin9 meanS ,0r trans,erri "9 «"* "it stream in 
ooiont T Segments ' J f n f where,n ln ° ^eans for estimating the position is adapted to estimate the 
position In dependence on an end of one of the segments. 

82. Apparatus according to Claim 81 . further comprising means for predetermining the size of at least one segment. 

M ' J™1 S ,0r H manlpu,a ; in 9 a bit stream - comprising means for transferring the bit stream in a plurality of discrete 
segments, and means for estimating a position In the bit stream in dependence on a property of one of the seg 

84. Apparatus according to Claim 83, further comprising means for predetermining the size of a segment. 

85. Apparatus according to Claim 82 or 84, wherein the means for predetermining the size is adapted to predetermine 
a size equivalent to less than a portion of the bit stream associated with the position. 

86. Apparatus according to any of Claims 82, 84 and 85, wherein the means for predetermining the size is adapted 
to predetermine the size in dependence on a characteristic of the bit stream. 

87. Apparatus according to any of Claims 82 and 84 to 86, wherein the means for predetermining the size is adapted 
to predetermine the size in dependence on a bit rate of the bit stream. 

88. Apparatus according to any of Claims 82 and 84 to 87, wherein the means for predetermining the size is adapted 
to predetermine a constant size. 

89. Apparatus according to any of Claims 82 and 84 to 88, wherein the means for predetermining the size comprises 
a static filter. r 

90. Apparatus according to any of Claims 82 and 84 to 87, wherein the means for predetermining the size is adapted 
to predetermine a variable size. 

91 ' a P i na^c fitter rdi " 9 * ^ °' C ' aimS "* ** * 9 °' WhSrein thS m6anS '° r P redeterminin 9 the size comprises 

92. Apparatus according to any of Claims 82 and 84 to 91 , wherein the means for predetermining the size comprises 
at least one of a rapid dynamic filter, an inertial dynamic filter, and a hybrid dynamic filter. 

93. Apparatus according to any of Claims 61 to 72 and 82 to 92, wherein the means for estimating the position is 
adapted to take into account an error in at least one previous estimate. 

94. Apparatus according to any of Claims 61 to 72 and 82 to 93, further comprising means for estimating the position 
in dependence on at least one characteristic of the bit stream. 

95. Apparatus for evaluating a position in a bit stream, comprising means for estimating the position in dependence 
on at least one characteristic of the bit stream. 

96. Apparatus according to Claim 94 or 95, wherein the or each characteristic Is at least one of a bit rate of the bit 
stream, the relative position within the bit stream, and the time elapsed between parts of the bit stream. 

97. Apparatus according to any of Claims 94 to 96, further comprising means for estimating a measure of separation 
between the occurrence of the position and the occurrence of an event relating to the position. 

98. Apparatus according to Claim 97. wherein the means for estimating the position in the bit stream is adapted to 
incorporate the measure of separation, preferably in conjunction with an estimate of the bit rate of the bit stream 
close to the position in the bit stream. 
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100.A receiver/decoder incomorating apparatus as claimed in any of Claims 61 to 99. 
101 .A method of evaluating a position in a bit stream, comprising estimating the position. 

^^^S i ZS^ n 3 ^ Str6am ' C ° mpriSin9 - " on a, leas, 

105. A broadcast system comprising a broadcast centre and a receiver/decoder as claimed in Claim 100. 

106. A computer program product adapted to carry out a method as claimed in any of claims 1 01 to 1 04. 

107. A computer readable medium having stored thereon a computer program product as Calmed in Cairn 1 06. 

108. A signal tangibly embodying a computer program product as claimed in Claim 106. 

10 *J SHE COntr °" in9 tranSf6r ° f 3n aUdi0/ViSUa, bit stream ■ ^ 'he transfer speed is represented as 

110.A command according to Claim 1 09, wherein the speed is positive, zero and/or negative. 

111 f ra n~ 

112 V^ a e n d^r a Tall7 ° f C ' aimS 10 Wh6rein 9 P0Siti °" at WhiCh "» *— * «• ^ take place is 

113 fo sstss r a Va™ n :ii a r n audio/visuai bit s,ream ' wherein the ^ - — - - 

116.A command set. comprising at least one command as claimed in any of the preceding claims 

'~«r«s r„ir,T M M — * ,he — ■ - >— ■ — - 
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to 115, with a parameter equivalent to a position in the audio/visual bit stream. 

121. A command according to any of Claims 118 to 120, adapted to invoke a command as claimed in any of Claims 
1 09 to 1 1 1 , with a parameter equivalent to zero speed. 

122. A command according to any of Claims 118 to 121, adapted to Invoke a command as claimed In any of Claims 
1 09 to 1 1 1 , with a parameter equivalent to a greater than normal playback speed. 

123. A command according to any of Claims 118 to 122, adapted to invoke a command as claimed in any of Claims 1 
to 3, with a parameter equivalent to a less than normal playback speed. 

124. A command according to any of Claims 118 to 123, adapted to invoke a command as claimed in any of Claims 
1 09 to 1 1 1 , with a parameter equivalent to a negative playback speed. 

1 25. A command according to any of Claims 1 1 8 to 1 24, adapted to invoke a command as claimed in any of Claims 1 
to 3, with a parameter equivalent to a normal playback speed. 

126. A command according to any of Claims 118 to 125, adapted to invoke a command as claimed in any of Claims 
1 1 2 to 11 5, with a parameter equivalent to the location. 

1 27. A command according to any of Claims 1 1 8 to 1 26, adapted to cause the or a further audio/visual bit stream to be 
stored. 

1 28. A command for controlling the transfer of an audio/visual bit stream, the command adapted to invoke at least one 
command as claimed in any of Claims 11 8 to 127. 

1 29. A command as claimed in any of Claims 1 09 to 1 1 5 and 1 1 8 to 1 28, wherein the command corresponds to a user- 
selectable audio/visual control operation. 

130. A method of controlling the transfer of a audio/visual bitstream, comprising comparing a command according to 
any of Claims 109 to 115 or 118 to 129 to a control criterion, and generating a further command if the command 
does not match the control criterion. 

1 31 .A method according to Claim 1 30, wherein the command is a further command generated according to Claim 1 30. 

132. A method according to Claim 130 or 131 , wherein the control criterion is dependent upon a characteristic of the 
transfer of the audio/visual bitstream, preferably of the transfer occurring at the time of receipt of the command. 

133. A method according to Claim 132, wherein the characteristic of the transfer of the audio/visual bitstream is a 
transfer speed and or a position in the bitstream, 

134. A method according to any of Claims 1 30 to 1 33, wherein the control criterion is dependent upon conditional access 
and or parental control data. 

135. An operating system, comprising at least one command as claimed in any of Claims 109 to 115 and 118 to 128, 
preferably adapted to carry out a method according to any of Claims 130 to 134, 145 or 146. 

136. A receiver/decoder, comprising at least one command as claimed in any of Claims 109 to 115 and 118 to 128, 
preferably adapted to carry out a method according to any of Claims 130 to 134, 145 or 146. 

1 37. A receiver/decoder, adapted to invoke at least one command as claimed in any of Claims 1 09 to 1 1 5 and 1 1 8 to 1 28. 

138. A computer program product, comprising at least one command as claimed in any of Claims 109 to 115 and 118 
to 1 28. 

139. A computer readable medium, comprising a computer program product as claimed in Claim 138. 

140. A signal, tangibly embodying a computer program product as claimed in Claim 138. 
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to 126 and or carrying out a method according to any of Claims 130 to 134, 145 or 146. 

142 l P , P r tUS Pr0C ! S f " 9 audio/visua » data - comprising an input, an output, and a processor and associated mem- 

UB to 1 P 6°?n S H ^ r " 9 * - ™ C ° mmand 38 C,aimed "V of Claims 109 to ""and 

118 to 126, and or to carry out a method according to any of Claims 130 to 134, 145 or 146. 

143. An audio/visual processing device, comprising apparatus as claimed in Claim 141 or 142. 

144. A broadcast system, comprising a receiver/decoder according to Claim 136 or 137. 

145 tTe^ 

speed, and passing the transfer speed as a parameter to the command. 

whl° d h°i '°" tr0,lin9 !"! TT 01 a " audi0/visual bit stream . comprising invoking a command to set a position 
at which the transfer is to take place, and passing the position as a parameter. 
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FIG. 3 
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FIG. 5 
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